Mvc3 ellipsis

Question

we have a specific problem with the anti-fake token on the login page. If the user logs in with only one active window, everything works fine, if the user opens the login page in two different windows and logs in to window A (no problems will be logged in), and the user returns to the login from window B in this window will receive "The required anti-counterfeit token was not specified or was invalid."

Is there a way around this other one to remove the anti-fake token from the view / controller action? We would rather have a token for added security!

This is very similar to this question, however it was asked for mvc2 MVC ValidateAntiForgeryToken with multiple tabs

Answer 1

This behavior is designed in MVC3 or MVC4, however, it is very unfriendly to the user, as described above, however, in production this problem must be elegantly solved, and the application must deal with this strange situation. The solution to this problem is to create a filter that is applied to the login message, which checks whether the user is registered and displays them on the correct page, otherwise they will remain on the login page.

Below is the filter attribute code

/// <summary> /// Handle Antiforgery token exception and redirect to customer area if the user is Authenticated /// </summary> public class RedirectOnError : HandleErrorAttribute { /// <summary> /// Override the on exception method and check if the user is authenticated and redirect the user /// to the customer service index otherwise continue with the base implamentation /// </summary> /// <param name="filterContext">Current Exception Context of the request</param> public override void OnException(ExceptionContext filterContext) { if (filterContext.Exception is HttpAntiForgeryException && filterContext.HttpContext.User.Identity.IsAuthenticated) { // Set response code back to normal filterContext.HttpContext.Response.StatusCode = 200; // Handle the exception filterContext.ExceptionHandled = true; UrlHelper urlH = new UrlHelper(filterContext.HttpContext.Request.RequestContext); // Create a new request context RequestContext rc = new RequestContext(filterContext.HttpContext, filterContext.RouteData); // Create a new return url string url = RouteTable.Routes.GetVirtualPath(rc, new RouteValueDictionary(new { Controller = "CustomerArea", action = "Index" })).VirtualPath; // Check if there is a request url if (filterContext.HttpContext.Request.Params["ReturnUrl"] != null && urlH.IsLocalUrl(filterContext.HttpContext.Request.Params["ReturnUrl"])) { url = filterContext.HttpContext.Request.Params["ReturnUrl"]; } // Redirect the user back to the customer service index page filterContext.HttpContext.Response.Redirect(url, true); } else { // Continue to the base base.OnException(filterContext); } } } 

This is an example of use.

  [HttpPost] **[RedirectOnError]** [ValidateAntiForgeryToken] public ActionResult LogOn(LogOnViewModel model, UserSessionState session, string returnUrl) { ..... } 

Answer 2

After logging in, all previous tokens are invalid. This is how it should work. Naz gets close to the correct answer, except that the token in the cookie does not store the username. Only token in form. It is precisely because of this problem: if the user logs in, all existing form tokens must be invalid, but the invalidity of the cookie itself will be too problematic and unfriendly for the user.