Aspnetcore: Antiforgery token was meant for a different claims-based user than the current user

[drauch]

We have a UseStatusCodePagesWithReExecute middleware in place which executes a 404 error action and returns a view. We have a user-feedback form on all our views (which is also included on the 404 page). The feedback form works fine on every page - BUT - on the 404 page sending feedback runs into:

Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException:
The provided antiforgery token was meant for a different claims-based user than the current user.

Do we need to do something special in this scenario to make the token valid too?

[kichalla]

It would be helpful to understand how the UI flow is like. For example, user had logged in or logged out and when is the 404 happening.

We have a user-feedback form on all our views

Curious, how is the feedback form generated on every view? using some partial view or something else?

[drauch]

We've debugged the problem further and found the problem:

app.UseUseStatusCodePagesWithReExecute("/Error");
....
app.UseCookieAuthentication(...);

In case of a 404 error the cookie authentication is executed twice and it re-adds the claims although they are already existent. Therefore the ClaimsPrincipal gets the same claims twice and is considered different by the antiforgery token checker.

Is there a way to configure the CookieAuthentication in such a way that it doesn't readd the claims if they already exist?

We could move the cookie authentication BEFORE the status code pages middleware, however, this would be a problem if the cookie auth middleware returns 403 in case of accesss denied. Then the user would not get our nice 403 view.....

What's the recommended order of those middlewares? Do we have a problem in the ordering?

[Tratcher]

2.0 should solve this, Cookie auth should avoid the duplication.

[drauch]

So, in other words, when using 1.x this is a non-supported scenario? :-/ No workaround whatsoever? :-/

[Tratcher]

You could put CookieAuth first. CookieAuth doesn't return 403s, it redirects.

[mkArtakMSFT]

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.