I'm developing a web site in Blazor Server Side. My Login page is a Razor Page and everything works as expected, but if a user leaves their browser open for a period of time around 20 minutes and then performs the login they get an Http Error 400. I think it is for the Anti Forgery Token, because if you delete the cookie ".AspNetCore.Antiforgery" you got the same error. What should I do to solve this issue? What do you recommend?
If the application is being hosted in IIS I recommend setting Load User Profile = True in the application's app pool > Advanced settings menu. I had a similar issue in the past and I noticed every time the application restarted in IIS the keys were not persisted and any form opened before the restart is useless. However as soon as I changed the setting the key persisted. https://codeshorts.com/ASP-NET-Core-IIS-Invalid-Anti-Forgery-Token-Error-400
This also seems to have been an issue with Azure hosted apps
https://stackoverflow.com/a/52302702/1843966
You can try to apply IgnoreAntiforgeryToken Attribute to LoginModel class to skip antiforgery token validation, like below.
[AllowAnonymous]
[IgnoreAntiforgeryToken]
public class LoginModel : PageModel
{
//...
Note: normally, disabling antiforgery token validation is not recommended. But in this thread, applying it to LoginModel (user login functionality) should be fine.
I found this approach using code so you can catch the exception if it does fail
Related
I want to get current windows user name when user opens the website. My application uses Blazor server-side. To get current username, I added:
In startup.cs:
services.AddHttpContextAccessor(); (under
ConfigureServices)
In razor page:
#inject IHttpContextAccessor httpContextAccessor
In razor page method:
string userName = httpContextAccessor.HttpContext.User.Identity.Name;
When I execute the code, the application throws an exception:
"An error has occurred. This application may no longer respond until reloaded."
I get this error only when I deploy on IIS. On local machine it works well.
I had a similar issue trying to access HttpContext for user information using Blazor. I found this here which was a life saver. HttpContext is NULL when running web app in IIS
All I had to do to solve the problem was to enable WebSockets in IIS.
Here are the steps: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/websockets?view=aspnetcore-3.1#iisiis-express-support
If you were to change that string from
string userName = httpContextAccessor.HttpContext.User.Identity.Name
to
string userName = httpContextAccessor?.HttpContext?.User?.Identity?.Name??"Anonymous"
then it would probably work.
It's because your IIS settings are allowing anonymous access and so your Identity object is null.
You should check for the inner exceptions behind the application crash but that will be your issue. You need to prevent anonymous access on IIS to get the Windows authentication passed through.
To manage IIS refer here https://stackoverflow.com/a/5458963/12285843
I am developing an application to be hosted in the Azure App Services environment which consists of a front-end Web App, a back-end Web API and a SQL Database (using Azure SQL). The front-end Web App is a Razor Pages app. We are trying to use the Microsoft Identity Platform (via Microsoft.Identity.Web and Microsoft.Identity.Web.UI libraries) to acquire an access token for the API when needed.
It works perfectly well the first time, but once a token has been acquired and cached - if the application is restarted it fails with this error:
IDW10502: An MsalUiRequiredException was thrown due to a challenge for the user. See https://aka.ms/ms-id-web/ca_incremental-consent.
No account or login hint was passed to the AcquireTokenSilent call.
Startup configuration is (I've tried various variants of this):
public void ConfigureServices(IServiceCollection services)
{
services.AddDistributedMemoryCache();
services.Configure<CookiePolicyOptions>(options =>
{
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
options.HandleSameSiteCookieCompatibility();
});
services.AddOptions();
services.AddMicrosoftIdentityWebAppAuthentication(Configuration)
.EnableTokenAcquisitionToCallDownstreamApi(new string[] { Configuration["Api:Scopes"] })
.AddInMemoryTokenCaches();
services.AddControllersWithViews(options =>
{
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
}).AddMicrosoftIdentityUI();
services.AddRazorPages().AddRazorRuntimeCompilation().AddMvcOptions(options =>
{
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
});
services.AddMvc();
//Other stuff...
}
I have tried for many days trying to find either a resolution workaround for this. I can catch the
error, but there is no action we can take programmatically that seems to clear the problem (the ITokenAcquisition interface does not offer the option to force an interactive login).
I have found that it is ONLY a problem in a Razor Pages application - a controller-based MVC Web App with almost identical startup code does not exhibit the problem.
I have also found that, by creating a controller-based test MVC Web App and configuring it with the same client id, tenant id etc. as the app we're having problems with, then starting it up (within the Visual Studio development environment) as soon as the main app gets the problem, I can clear the error condition reliably every time. However this is obviously not a viable long-term solution.
I have searched for this problem on every major technical forum and seen a number of similar sorts of issues raised, but none provides a solution to this precise problem.
To replicate:
Create an ASP.NET Core 3.1 Web API.
Create an ASP.NET Core 3.1 Razor Pages Web App that calls the API.
Register both with Azure Active Directory and configure the App to request a token to access the API (as per various MS documents).
Run - if everything is set up correctly the login screen will appear and all will work correctly.
Stop the Web App, wait a couple of minutes and re-start. The error above will now appear.
I have raised a Microsoft support request for it - has anybody else come across this and found a solution for it?
I have finally got to the bottom of this, largely thanks to this: https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/issues/216#issuecomment-560150172
To summarise - for anyone else having this issue:
On the first invocation of the web app you are not signed in, and so get redirected to the Microsoft Identity Platform login, which logs you in and issues an access token.
The access token is stored in the In-Memory token cache through the callback.
All then works as expected because the token is in the cache.
When you stop, and then re-start the web app within a reasonably short time, it uses the authentication cookies to pick up the still-current login, and so it does not access the Identity Platform and you do NOT get an access token.
When you ask for a token the cache is empty - so it throws the MsalUiRequiredException.
What isn't really made clear in any of the documentation is that this is supposed to happen - and that exception is picked up by the "AuthorizeForScopes" attribute but only if you allow the exception to fall all the way through and don't try to handle it.
The other issue is that in a Razor Pages app the normal AuthorizeForScopes attribute has to go above the model class definition for every page - and if you miss one it may trigger the above problem.
The solution proposed by "jasonshave" in the linked article solves that problem by replacing the attribute with a filter - so it will apply to all pages.
Maybe I'm a bit old-school, but the idea of using an unhandled exception as part of a planned program control flow doesn't sit right with me - at the very least it should be made clear that that's the intention. Anyway - problem now solved.
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.
I am using identityserver4 for all configured clients with "AccesssTokenType=1" i.e. reference type.
I have one web app hosted for server, and other one for clients.
I used default identityserver settings, which generated two cookie, one for session Id "idsrv.session", and other one for authentication "idsrv".
In logout I do signout
await HttpContext.SignOutAsync(IdentityServerConstants.ExternalCookieAuthenticationScheme);
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);
however it gives error when I call with "idsrv.session"
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCheckSessionCookieName);
Issue / Steps to reproduce the problem
1st Iteration : Login on my client website which redirects to my identityserver application. I now interceprt the request and response using "Burp Suite". I copy the complete response which has redirect URL's and cookie details.
I signout/logout from client website.
2nd Iteration : I tried login again, and intercepted the request and response using Burp Suite, by passing wrong credential. While Intercepting the response I just copied the cookies from previous request (which was successful in my first iteration), and observe that identityserver has successfully validated the user using the cookie value, ignoring the wrong credentials in this iteration.
Even I tried invalidating and deleting cookies in my signout/logout method, but looks like identityserver still recognises it as the valid ones.
Brock Allen directed me to the corrrect solution. According to him :
This is the real issue you're asking about -- when you signout, you want the cookie to no longer be valid, even in the scenario when it's stolen and replayed. This is not something IdentityServer can address, because we use Microsoft's cookie authentication to achieve signin. You would have to fix this by changing the default usage of their component. You can do it by implementing "server-side cookie" (a term that I dislike) by implementing an ITicketStore: https://github.com/aspnet/Security/blob/master/src/Microsoft.AspNetCore.Authentication.Cookies/CookieAuthenticationOptions.cs#L136
Details Here
https://github.com/IdentityServer/IdentityServer4/issues/2565
I am nearly finished migrating an ASP.NET Core app from RC1 to 1.1.0. Everything is working great until I try to publish the app and host it in IIS.
In a debugger, or working directly from Kestrel, I have no problems. I can reach my site, login, and interact with it normally.
Under IIS, however, I can load the site and am correctly redirected to my login page, but despite logging in with the correct credentials, I am redirected back to the home page and am not logged in. I can repeat this cycle over and over - I am authenticating, but some part of the IIS/Core middleware isn't keeping me logged in.
My site is using ASP.NET Core Identity which is largely unchanged from the RC1 default VS project template.
AccountController:
//
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)
{
if (ModelState.IsValid)
{
var signInStatus = await SignInManager.PasswordSignInAsync(model.UserName, model.Password, model.RememberMe, false);
if (signInStatus.Succeeded)
return RedirectToLocal(returnUrl);
ModelState.AddModelError("", "Invalid username or password.");
return View(model);
}
// If we got this far, something failed, redisplay form
return View(model);
}
Unfortunately, I can't debug this, because the VS debugger hooks Kestrel, and when hosting natively from Kestrel this problem doesn't exist. I'm not able to attach my debugger to the running Kestrel process (that was launched by IIS) - I can get attached but my breakpoints will not attach.
I am certain that the method above is being called. If I enter an incorrect password, I do indeed see the "Invalid username and password" prompt. When I login "successfully", I am redirected to the original page. The problem is that after the redirect, I'm not logged in - the navbar still shows my Login button instead of the Logout button, and I can't interact with any authorized controllers.
I know this is a super vague question with little source, but I'm not sure where to even start with this one. I'm hoping someone might see what my problem is and point me in the right direction, or at least be able to suggest some steps I can take to isolate and try to debug the issue. Or, barring that, even some hints as to what information I can add to my question to give necessary details.
Thank you!
Two starting points you can try:
Install the latest Windows Server Hosting bundle on your server.
Monitor and compare traffic between the working and broken systems after you click the login button. Are you getting the Identity authentication cookie returned on the broken system similar to the working one?