I am currently writing an app in ASP.Net Core 3.1. Everything has been working fine on localhost (IIS Express) for weeks, but all of a sudden, my authentication has stopped working.
I am using AzureADB2C for authentication. Whenever my app needs to redirect to the login page, I get the following error in Edge/Chrome.
Hmmm… can't reach this page
It looks like the webpage at https://localhost:44344/ might be having issues, or it may have moved permanently to a new web address.
ERR_HTTP2_PROTOCOL_ERROR
The browser also displays a warning telling me that the Connection to this site isn't secure
When I use the Azure Portal to test my user flow, I can see that Azure is redirecting me back to https://localhost:44344/AzureADB2C/Account/Error#id_token=eyJ0{snip}. The token actually seems to be valid, but I am not sure why Azure is redirecting to an error page.
Here are my Azure Ad B2C settings
"AzureAdB2C": {
"Instance": "https://MY_COMPANY_NAME.b2clogin.com",
"ClientId": "MY_CLIENT_ID",
"CallbackPath": "/signin-oidc",
"Domain": "MY_COMPANY_NAME.onmicrosoft.com",
"SignUpSignInPolicyId": "B2C_1_SignUpSignIn",
"ResetPasswordPolicyId": "B2C_1_PasswordReset",
"EditProfilePolicyId": ""
},
Everything was working perfectly fine this morning. After restarting my PC, I launched Visual Studio, and my app would no longer work. I tested my app on another PC, and got the same errors.
UPDATE: After testing my user flow in the Azure Portal, with my local app not running, it looks like Azure is correctly redirecting back to https://localhost:44344/signin-oidc#id_token={token}. So the redirect to the error page is happening within the auth middleware. No errors are written to the output window, so I have no idea what is going wrong.
I tried rolling back my app to a previous commit from a week ago, but I am still seeing the same issue with older code that used to work.
This appears to be an issue with Windows. I recently updated to Insider Build 19587.rs_prerelease.200313-1639 and that's when the issue started occurring. After rolling back to 19582.rs_prerelease.200306-1640, my app authentication started to work again.
Related
I'm developing an app based on the Docusign C# Quickstart.
Its working fine on my development PC (Win 11) in Visual Studio 2019 using IIS Express.
However, when I publish it to IIS (v10) on my development PC it runs and I can authenticate with Docusign just fine (once I got the proper redirect URI registered: https://localhost/ds/callback) but the step that actually sends the envelope is returning the following error in the browser:
This page isn't working right now.
Local host can't handle this request
http error 500
Any help is appreciated. I logged a support ticket with Docusign, but still waiting for a response.
Quickstart is just an app to show you how to use DocuSign APIs.
The redirect after signing is back to localhost, and your app, once ready to be deployed to server, has to be set with a proper URL, at which point you'll need to update the redirect URI to the one based on your server.
The 500 error is coming from your app, not from DocuSign. You need to figure out why your app cannot handle the URL that is set for redirect after signing by DocuSign.
The base API address demo.docusign.net/restapi is used to reach the development/ test platform. The na4.docusign.net/restapi address is one of DocuSign's (many) production platforms.
Remember that, once you have passed the Go-Live process, you have two Client IDs (integration keys) one for the test platform, one for all of the production platforms. Each has its own settings.
Added
The error
This page isn't working right now.
Local host can't handle this request http error 500
Is from IIS. Use IIS logging to see the URL request that is coming in that can't be handled.
To see if it is the redirect from the initial OAuth Authorization Code grant URL, examine the initial URL redirect to account.docusign.com (prod URL).
The redirect contained as a query parameter in the initial OAuth redirect must:
Be correct for your instance of IIS.
Be allowed by your setting for the client ID (integration key) in DocuSign
1, Be properly handled by your IIS and its app.
Using ASP.NET Core with the Identity framework.
I have a project running on Azure, with a SQL Server database, a web site and an API.
Suddenly, today when trying to login to the system (from the app that calls the API), it is stuck for around 15 seconds and then I get an error http 500.
I try to run the API function that authenticate the user from the local env. and was able to reproduce the bug.
The first line of the function is :
var user = await _userManager.FindByEmailAsync(model.Username);
This is the line the program is stuck till getting error message 500.
I don't even know how to approach this, I try to add a line that retrieves one of the user details, just to make sure the API can still talk to the database and it works fine.
How can check what is wrong with it? If I had the implementation of this function, maybe I can debug it.
Any suggestions?
I've got this .net core 2.2 app, and it works locally. It's got these two main projects, PictureLink.UI and PictureLink.API.
The UI side sends requests to POST and GET from the API side via the Angular frontend.
Locally, it works just fine. When it sends a GET to the UI side, it sends to URLs like: https://localhost:44343/UI/auth/DecodeJwtPayload <-- This works
And when it tries to access the API side, it sends to URLs like:
https://localhost:44343/API/photo/GetPhotos <-- This works
Locally, it works just fine.
Then I published it, and now the URLs are like:
https://{url}/UI/auth/DecodeJwtPayload <-- This works
And when it tries to access the API side, it sends to URLs like:
https://{URL}/API/photo/GetPhotos <-- And this returns a 404
I don't understand why it would work locally during testing and then stop working when we publish it.
Some articles suggested adding services.AddControllers() to ConfigureServices in Startup, but VS is telling me that's not a valid method.
I don't even know where to start looking. Is this a routing issue? And IIS issue? An AzureDevOps issue? A config issue?
I am so. Lost.
There are many reasons for the 404 error. You can try the following methods:
1.You need to publish your website and then point IIS website to the published folder.
2.Application pool must be set to No Managed code
3.Application Pool identity user IIS AppPool\{AppPoolName} must have read permissions on the published website folder. Change the identity of your application pool to ApplicationPoolIdentity. For application pool identity there will be user account with name IIS AppPool{Applicaiton Pool name} e.g. for DefaultAppPool the user account is IIS AppPool\DefaultAppPool so you can allow read/write access to your to Applicaiton Pool user on published application folder.
If you still can’t solve your problem, please publish your controller code and web.config file.
My current setup is like this. The entire project was built using the official docs here - https://identityserver4.readthedocs.io/en/latest/
API Server
Auth Server with local login, google login and github login
Console based c# client
JS based client
MVC based client.
(all of it, as described in the official docs)
Locally, all of them work beautifully. Able to login, access api endpoints, logout, redirect, the whole thing works smooth.
I have deployed all 5 of them to five different azure web apps. They all have the standard xyz.azurewebsites.net domains ready to use. Now, I have run into some problems.
the console C# client is able to talk to the deployed auth server, collect token using a local account on the auth server and make calls to the deployed API server. Based on this, I assume that both the api server and the auth server working hand in hand, as they should.
Problem #1 - the JS client keeps saying
'The login is blocked because of CORS Missing Allow Origin '
Problem #2 - the MVC client loads the auth server, and then the auth server gives me this error.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Note : I have set the CORS policy on the auth server, both these clients, under client definition as follows. I am not too concerned about keeping the auth server open, so dont mind if any and every domain can call the auth server.
AllowedCorsOrigins = { "*.*" },
Also Note : I have set the URLS in the code before deployment. all loclahost:port number lines have been replaced correctly with the corresponding now published URLs.
So, what am I missing out here?
Update 1
I was able to solve the CORS issue. Have posted a answer here on another question.
Not able to enable CORS for identity server 4 in asp.net core
Update 2
So, now, both the JS client and the MVC client, are giving identical errors.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Update 3
I have opened an issue which has log details.
https://github.com/IdentityServer/IdentityServer4/issues/4691
I am not sure if this counts as an answer, but posting for my own question, as it might might help others. Also, this is only a guess at this point.
I found out that the redirects were permanently stored in the database I used with EF migrations. That mean, local in memory redirects were being overwritten anyway by the database stored migrations. I believe this is the issue.
I also realized that the console app is working fine for it does not depend on redirect URLs where as the JS and MVC based clients dont work because they do depend on redirect URLs.
At this point, the best thing to do and for you (if you used EF migrations to store your auth server configuration) on database would be start over and switch to in memory only. Alternatively, you can try and update the database to suit your deployment requirements.
Ultimately, I believe, unless it is absolutely necessary, keep the auth server config (like redirects and CORS settings) in memory as they dont take up much value and are rarely changed.
I'm writing simple asp .net core 2.2 MVC app with individual authorization (ASP Identity) hosted on IIS 10. If user navigates to Login page, stays idle for 20+ minutes (which is IIS default timeout to terminate app pool) and click on log in button - browser gets a 400 response and shows blank page. If user updates (F5) login page before click to log in - everything works fine.
IIS pool settings all default, but pipeline is changed to No Managed Code.
APS Identity Code default too (only registration modified a little).
Can anyone suggest how to resolve this idle login case?
I tried to disable AntiForgery Token Validation but it doesn't help.
I resolved the issue. On my app pool settings loadUserProfile was set to False by default. After I changed it to True everything started to work fine.
Don't know why it cause problems in False state though.
I resolved this issue by removing the [ValidateAntiForgeryToken] from the method(for which pag in MVC application.