I have a fresh asp.net application which has facebook authentication button on it. When I do the authentication on localhost it works flawlessly but when I publish and try to do it on work4me.azurewebsites.net it comes up with the error:
An error occurred while processing your request.
I have set the appID, app secret, domain, correct URL, and http://work4me.azurewebsites.net/signin-facebookas the oauth redirect URI. But it seems like it is hanging for a bit saying "waiting for domain name" before giving me the error.
If I try to enable facebook authentication on the azure portal it works however after logging in the application crashes and gives me the error "Server Error in '/' Application.".
I have followed the guide to enable facebook authentication on azures website but with no luck.
What am I doing wrong here?
EDIT:
It seems to get past that point now, and the error is with the redirect URI. However I have followed this example and use the URL https://work4me.azurewebsites.net/.auth/login/facebook/callback as the guide says but still it wont work, giving me the error that the URI is blocked.
It's been a few months since I first tried this, but I was able to get it working both locally and on Azure, by following the online instructions.
Did you enable User Secrets during development to access your credentials from Application Secrets? If so, you need to create environment variables in your Azure Web App to mirror these values under Application Settings.
Let me know if you still have any issues, then I can look into it some more.
All the best! :)
Related
I have IIS 8.5.9600.16384 running on Windows Server 2012R2 and a website configured as application with separate application pool.
In IIS Authentication only "Anonymous Authentication" is enabled. To perform authentication, my site uses it's own login prompt and calls a .net core backend with basic schema, something like
POST /mycorebackend/login
with http header
Authorization: Portal base64encoded_username_and_password_here
Everything works just fine if authentication is successful and backend responds with HTTP OK.
But if backend returns 401 Unauthorized I've got pop-up from IIS asking me to provide credentials, like I'm trying to access a folder with some content, but I'm not.
I just need to get my 401 error and continue my js execution without any prompts.
Can anyone help or at least give a me hint where to search for?
I think this may be related to IIS-kestrel integration or so... For some reason IIS tries other schemes or so...
Thank you
I think you are looking for these settings. that should resolve it
I am setting up a custom oauth server with Rocket Chat (Meteor). Almost everything is okay, however Rocket Chat fails when trying to query the /oauth/token endpoint to log the user in.
The endpoint is not touched, so I guess the requests is not even sent. The
error is thrown here and the message is Parse Error.
I've tried to read the meteor/http code, but I did not manage to figure which package could be responsible to this Parse Error.
I can't figure the right way to get more info. Edit: I've tried to install Rocket Chat locally and could not reproduce. This error only happens on a live instance.
Any idea what could cause this issue or what step I could take to debug this?
This error "Parse Error" can appear when the URL is not correct but still a valid URL. The endpoint will return HTML instead of a valid JSON and thus produce this error.
Example: you host your Rocket Chat on "my-chat.com", and use "localhost:3000/oauth", on your own development machine, as your oauth server.
This will fail, because Rocket Chat will query "localhost:3000", but from the Rocket Chat standpoint localhost is the server it is hosted on, not your own machine. So the request will hit Rocket Chat itself instead of your local development server and produce this error.
I have successfully, or so I thought, connected up to our IDP for single sign on with shibboleth. I went to the Shibboleth test login page and was prompted by our IDP to login. Once I logged in, it gave me an error saying that the site can't be reached and that the server IP address could not be found. I have tried going to the logout and status pages and get that same error. I am not seeing anything in the shibd logs that indicate any errors. I have tried resetting my shibboleth daemon and my IIS and still am getting the same error.
Could this be something to do with my shibboleth2.xml configuration? I am not sure how the server IP address would be affected by this.
I can provide any needed information you may need!
If your secured url is https://local-or-some-domain/secure, when you hit that URL and you are taken to idP, after successful login you are taken back to the same URL but the browser says nothing found.
If above is your scenario then congratulations, you have successfully integrated the shibboleth SP with idP. Most of the time error occurs because there is no page hosted to the URL we secured.
If above is not your scenario then you may want to elaborate little more.
I have an ASP.NET MVC app, running as Azure Web App.
I use pre-authentication/EasyAuth, and for 5 deployment slots it works fine. Each of them has their own Azure AD App Registration.
But the production site (not a deployment slot, root of the app) throws an error when after logging in, at the /.auth/login/aad/callback path:
I have compared Azure AD App manifest with one that works, and the only difference is the names, description and URLs - as expected.
Using Kudu to view an error, it seems to come from the EasyAuthModule:
So, basically this was an issue with the App Registration used, were created from another deployment slot.
Even though Authentication / Authroization for the web app was set up as Express, the correct App Registration was selected - it turns out it did not get the Client Secret transferred from App Registration to the Web App (in my case, it had the wrong key):
To fix it, you can switch to advanced as shown above, open the associated App Registration and create a new key:
The key is not shown until you save, and is only shown once. Copy it, and insert it into the Client Secret input of the Web App.
After saving all the blades, it is possible to switch back to Express auth. setup and the key will remain.
As I cannot comment I'll add my case as an answer in a bit more detail than I would have to a comment.
I had the exact same error messages From Easyauth in an ASP.NET MVC app running as Azure App Service Web App.
The initial error message was just "The page cannot be displayed because an internal server error has occurred." And via FTP and/or Visual Studio Server Explorer and/or Cloud Explorer I could check the real error page after setting the detailed error messages on from App Service Logs. Those errors were the same as with MartinHN got using Kudu.
So in the more detailed error the predominantly shown 500.74 error originally pointed me to the wrong direction (MFA). But Request Url (.auth/login/aad/callback ) where the error message indicated the internal server error was occurring in, led me to this SO question.
In my case though I had the Advanced Configuration already selected in App Services Active Directory Authentication. And the client secret key was not just wrong. It turned out that the client secret had expired. But it wasn’t obvious to me as I don’t have access to the AAD. I had to contact a separate AD team to check the secrets.
So expired client secret (keys) can also cause this very same error.
I have a webapp which is a .NET 4, webforms app running on IIS 7.5 on Server 2008. Recently and apparently sporadically users trying to use the app on a mac are being presented with an error page stating:
401 Unauthorized - Access is denied due to invalid credentials.
You do not have the permission to view this directory using the credentials that you supplied.
The page doesn't provide any further information or substatus codes. I have checked the IIS error logs for more information and have found that this issue does seem to be unique to users on a mac most commonly Safari but it does also happen on other browsers such as Firefox. Again no substatus code is provided in these logs.
The error message provided seems to be consistent with a 401.1 however I am using forms authentication and not windows authentication. I have been unable to reproduce this myself and at the moment it apparently happens at random for users and not consistently after a set of specific steps.
This error occurs when users are in the app or trying to log in, I do not think it is related to them entering invalid credentials as I have validation to handle that and it can happen to users already logged into the app.
As I can't reproduce the error I am not sure how to approach solving this problem, I would like some guidance to this regard and any solutions or ideas that you guys can come up with. If more information is needed let me know and I can update the question.
EDIT:
I had an idea that maybe some configuration on a mac was causing a WWW-Authenticate header to be sent when it isn't required, but after using TamerData to add the header I found I still couldn't replicate the issue. All authentication in IIS is disabled with the exception of anonymous and forms.
EDIT 2:
I have now been able to successfully reproduce the issue, it occurs when an unauthenticated user attempts to access a protected page with a ?ReturnUrl=value parameter. This will cause IIS to display the error page described above. I can fix this behaviour by removing the ReturnUrl parameter on any unauthenticated attempts to access a protected page and redirect the user to the login page in Begin_Request.
However this issue has been reported most commonly on a page which is redirected to immediately after a user has just logged in. So for some reason the user is still being sent a 401 error when they are in fact authenticated. Any idea why this would be?