Anti forgery token is meant for user “” but the cu

Question

I'm building a single page application and experiencing an issue with anti-forgery tokens.

I know why the issue happens I just don't know how to fix it.

I get the error when the following happens:

1. Non-logged-in user loads a dialog (with a generated anti-forgery token)
2. User closes dialog
3. User logs in
4. User opens the same dialog
5. User submits form in dialog

Anti forgery token is meant for user "" but the current user is "username"

The reason this happens is because my application is 100% single-page, and when a user successfully logs in through an ajax post to /Account/JsonLogin, I simply switch out the current views with the "authenticated views" returned from the server but do not reload the page.

I know this is the reason because if I simple reload the page between steps 3 and 4, there is no error.

So it seems that @Html.AntiForgeryToken() in the loaded form still returns a token for the old user until the page is reloaded.

How can I change @Html.AntiForgeryToken() to return a token for the new, authenticated user?

I inject a new GenericalPrincipal with a custom IIdentity on every Application_AuthenticateRequest so by the time @Html.AntiForgeryToken() gets called HttpContext.Current.User.Identity is, in fact my custom Identity with IsAuthenticated property set to true and yet @Html.AntiForgeryToken still seems to render a token for the old user unless I do a page reload.

Answer 1

[OutputCache(NoStore=true, Duration=0, VaryByParam="None")]

public ActionResult Login(string returnUrl)

You can test this by putting a break point on the first line of your Login (Get) action. Before adding the OutputCache directive the breakpoint would be hit on the first load, but after clicking the browser back button it wouldn’t. After adding the directive you should end up with the breakpoint being hit every time, so the AntiForgeryToken will be the corect one, not the empty one.

Answer 2

I had the same issue with a single-page ASP.NET MVC Core application. I resolved it by setting HttpContext.User in all controller actions which change the current identity claims (since MVC only does this for subsequent requests, as discussed here). I used a result filter instead of middleware to append the antiforgery cookies to my responses, which made sure that they were only generated after the MVC action had returned.

Controller (NB. I'm managing users with ASP.NET Core Identity):

[Authorize]
[ValidateAntiForgeryToken]
public class AccountController : Controller
{
    private SignInManager<IdentityUser> signInManager;
    private UserManager<IdentityUser> userManager;
    private IUserClaimsPrincipalFactory<IdentityUser> userClaimsPrincipalFactory;

    public AccountController(SignInManager<IdentityUser> signInManager, UserManager<IdentityUser> userManager, IUserClaimsPrincipalFactory<ApplicationUser> userClaimsPrincipalFactory)
    {
        this.signInManager = signInManager;
        this.userManager = userManager;
        this.userClaimsPrincipalFactory = userClaimsPrincipalFactory;
    }

    [HttpPost]
    [AllowAnonymous]
    public async Task<IActionResult> Login(string username, string password)
    {
        if (username == null || password == null)
        {
            return BadRequest(); // Alias of 400 response
        }

        var result = await signInManager.PasswordSignInAsync(username, password, false, lockoutOnFailure: false);
        if (result.Succeeded)
        {
            var user = await userManager.FindByNameAsync(username);

            // Must manually set the HttpContext user claims to those of the logged
            // in user. Otherwise MVC will still include a XSRF token for the "null"
            // user and token validation will fail. (MVC appends the correct token for
            // all subsequent reponses but this isn't good enough for a single page
            // app.)
            var principal = await userClaimsPrincipalFactory.CreateAsync(user);
            HttpContext.User = principal;

            return Json(new { username = user.UserName });
        }
        else
        {
            return Unauthorized();
        }
    }

    [HttpPost]
    public async Task<IActionResult> Logout()
    {
        await signInManager.SignOutAsync();

        // Removing identity claims manually from the HttpContext (same reason
        // as why we add them manually in the "login" action).
        HttpContext.User = null;

        return Json(new { result = "success" });
    }
}

Result filter to append antiforgery cookies:

public class XSRFCookieFilter : IResultFilter
{
    IAntiforgery antiforgery;

    public XSRFCookieFilter(IAntiforgery antiforgery)
    {
        this.antiforgery = antiforgery;
    }

    public void OnResultExecuting(ResultExecutingContext context)
    {
        var HttpContext = context.HttpContext;
        AntiforgeryTokenSet tokenSet = antiforgery.GetAndStoreTokens(context.HttpContext);
        HttpContext.Response.Cookies.Append(
            "MyXSRFFieldTokenCookieName",
            tokenSet.RequestToken,
            new CookieOptions() {
                // Cookie needs to be accessible to Javascript so we
                // can append it to request headers in the browser
                HttpOnly = false
            } 
        );
    }

    public void OnResultExecuted(ResultExecutedContext context)
    {

    }
}

Startup.cs extract:

public partial class Startup
{
    public Startup(IHostingEnvironment env)
    {
        //...
    }

    public IConfigurationRoot Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {

        //...

        services.AddAntiforgery(options =>
        {
            options.HeaderName = "MyXSRFFieldTokenHeaderName";
        });


        services.AddMvc(options =>
        {
            options.Filters.Add(typeof(XSRFCookieFilter));
        });

        services.AddScoped<XSRFCookieFilter>();

        //...
    }

    public void Configure(
        IApplicationBuilder app,
        IHostingEnvironment env,
        ILoggerFactory loggerFactory)
    {
        //...
    }
}

Answer 3

The message appears when you login when you are already authenticated.

This Helper does exactly the same thing as [ValidateAntiForgeryToken] attribute.

System.Web.Helpers.AntiForgery.Validate()

Remove the [ValidateAntiForgeryToken] attribut from controller and place this helper in action methode.

So when user is already authentificated, redirect to the home page or if not continue with the verification of the valid anti-forgery token after this verification.

if (User.Identity.IsAuthenticated)
{
    return RedirectToAction("Index", "Home");
}

System.Web.Helpers.AntiForgery.Validate();

To try to reproduce the error, proceed as follows: If you are on your login page and you are not authenticated. If you duplicate the tab and you login with the second tab. And if you come back to the first tab on the login page and you try to log in without reloading the page ... you have this error.

Answer 4

It happens a lot of times with my application, so I decided to google for it!

I found a simple explanation about this error! The user are double-clicking the button for login! You can see another user talking about that on the link below:

MVC 4 provided anti-forgery token was meant for user "" but the current user is "user"

I hope it helps! =)

Answer 5

This is happening because the anti-forgery token embeds the username of the user as part of the encrypted token for better validation. When you first call the @Html.AntiForgeryToken() the user is not logged in so the token will have an empty string for the username, after the user logs in, if you do not replace the anti-forgery token it will not pass validation because the initial token was for anonymous user and now we have an authenticated user with a known username.

You have a few options to solve this problem:

1. Just this time let your SPA do a full POST and when the page reloads it will have an anti-forgery token with the updated username embedded.

2. Have a partial view with just @Html.AntiForgeryToken() and right after logging in, do another AJAX request and replace your existing anti-forgery token with the response of the request.

3. Just disable the identity check the anti-forgery validation performs. Add the following to your Application_Start method: AntiForgeryConfig.SuppressIdentityHeuristicChecks = true.

Answer 6

To fix the error you need to place the OutputCache Data Annotation on the Get ActionResult of Login page as:

[OutputCache(NoStore=true, Duration = 0, VaryByParam= "None")] 
public ActionResult Login(string returnUrl)