Anti forgery token está destinado para el usuario ""pero el usuario actual es" nombre de usuario"

Para corregir el error, debe colocar la Anotación de datos OutputCache en la página Get ActionResult de inicio de sesión como:

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

Sucede muchas veces con mi aplicación,así que decidí buscar en Google!

He encontrado una explicación simple sobre este error! El usuario está haciendo doble clic en el botón para iniciar sesión! Puedes ver a otro usuario hablando de eso en el siguiente enlace:

MVC 4 proporcionado anti-falsificación token estaba destinado para el usuario ""pero el usuario actual es "usuario"

¡Espero que ayude! =)

Tuve el mismo problema, y este truco sucio lo arregló, al menos hasta que pueda arreglarlo de una manera más limpia.

    public ActionResult Login(string returnUrl)
    {
        if (AuthenticationManager.User.Identity.IsAuthenticated)
        {
            AuthenticationManager.SignOut();
            return RedirectToAction("Login");
        }

...

Tuve un problema bastante específico pero similar dentro del proceso de registro. Una vez que el usuario haga clic en el enlace de correo electrónico que se le envía, se inicia sesión y se envía directamente a una pantalla de detalles de la cuenta para completar más información. Mi código era:

    Dim result = Await UserManager.ConfirmEmailAsync(userId, code)
    If result.Succeeded Then
        Dim appUser = Await UserManager.FindByIdAsync(userId)
        If appUser IsNot Nothing Then
            Dim signInStatus = Await SignInManager.PasswordSignInAsync(appUser.Email, password, True, shouldLockout:=False)
            If signInStatus = SignInStatus.Success Then
                Dim identity = Await UserManager.CreateIdentityAsync(appUser, DefaultAuthenticationTypes.ApplicationCookie)
                AuthenticationManager.SignIn(New AuthenticationProperties With {.IsPersistent = True}, identity)
                Return View("AccountDetails")
            End If
        End If
    End If

Encontré que la vista Return ("AccountDetails") me estaba dando la excepción token, supongo que porque la función ConfirmEmail estaba decorada con AllowAnonymous pero la función AccountDetails tenía Valida el rescate.

Cambiar el Retorno a Return RedirectToAction("AccountDetails") resolvió el problema para mí.

Tengo la misma excepción ocurriendo la mayor parte del tiempo en el servidor de producción.

¿por Qué sucede?

Sucede cuando el usuario inicia sesión con credenciales válidas y una vez iniciado sesión y redirige a otra página, y después de presionar el botón atrás se mostrará la página de inicio de sesión y de nuevo ingresó credenciales válidas que cuando se producirá esta excepción.

Cómo resolver?

Simplemente agregue esta línea y trabaje perfecto, no obtenga un error.

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

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

public ActionResult Login(string returnUrl)

Puede probar esto poniendo un punto de interrupción en la primera línea de su acción de inicio de sesión (Get). Antes de agregar la directiva OutputCache, el punto de interrupción sería alcanzado en la primera carga, pero después de hacer clic en el botón de retroceso del navegador no. Después de agregar la directiva, debería terminar con el punto de interrupción siendo alcanzado cada vez, por lo que el AntiForgeryToken será el corect, no el vacío.

Tuve el mismo problema con una sola página ASP.NET Aplicación MVC Core. Lo resolví configurando HttpContext.User en todas las acciones del controlador que cambian las notificaciones de identidad actuales (ya que MVC solo hace esto para solicitudes posteriores, como se discutió aquí). Utilicé un filtro de resultados en lugar de middleware para agregar las cookies antiforgery a mis respuestas, lo que se aseguró de que solo se generaran después de que la acción MVC hubiera regresado.

Controlador (NB. Estoy administrando usuarios con ASP.NET Básica Identidad):

[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" });
    }
}

Filtro de resultados para añadir cookies antiforgery:

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)
    {

    }
}

Inicio.extracto cs:

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)
    {
        //...
    }
}

El mensaje aparece cuando inicia sesión cuando ya está autenticado.

Este Ayudante hace exactamente lo mismo que el atributo [ValidateAntiForgeryToken].

System.Web.Helpers.AntiForgery.Validate()

Elimine el atributo [ValidateAntiForgeryToken] del controlador y coloque este ayudante en el método de acción.

Entonces, cuando el usuario ya está autenticado, redirija a la página de inicio o si no continúa con la verificación del token anti-falsificación válido después de esta verificación.

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

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

Para intentar reproducir el error, proceda como seguir: Si está en su página de inicio de sesión y no está autenticado. Si duplica la pestaña e inicia sesión con la segunda pestaña. Y si vuelves a la primera pestaña de la página de inicio de sesión e intentas iniciar sesión sin recargar la página ... tienes este error.

Tiene un problema con la validación anti-falsificación-token en internet-shop: los usuarios abren muchas pestañas (con los productos) y después de iniciar sesión en un intento de iniciar sesión en otro y consiguió tal AntiForgeryException. Por lo tanto, AntiForgeryConfig.SuppressIdentityHeuristicChecks = true no me ayudó, así que usé un hackfix tan feo, tal vez sea útil para alguien:

   public class ExceptionPublisherExceptionFilter : IExceptionFilter
{
    public void OnException(ExceptionContext exceptionContext)
    {
        var exception = exceptionContext.Exception;

        var request = HttpContext.Current.Request;
        if (request != null)
        {
            if (exception is HttpAntiForgeryException &&
                exception.Message.ToLower().StartsWith("the provided anti-forgery token was meant for user \"\", but the current user is"))
            {
                var isAjaxCall = string.Equals("XMLHttpRequest", request.Headers["x-requested-with"], StringComparison.OrdinalIgnoreCase);
                var returnUrl = !string.IsNullOrWhiteSpace(request["returnUrl"]) ? request["returnUrl"] : "/";
                var response = HttpContext.Current.Response;

                if (isAjaxCall)
                {
                    response.Clear();
                    response.StatusCode = 200;
                    response.ContentType = "application/json; charset=utf-8";
                    response.Write(JsonConvert.SerializeObject(new { success = 1, returnUrl = returnUrl }));
                    response.End();
                }
                else
                {
                    response.StatusCode = 200;
                    response.Redirect(returnUrl);
                }
            }
        }


        ExceptionHandler.HandleException(exception);
    }
}

public class FilterConfig
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new ExceptionPublisherExceptionFilter());
        filters.Add(new HandleErrorAttribute());
    }
}

Creo que será genial si se pueden establecer opciones de generación de tokens anti-falsificación, para excluir el nombre de usuario o algo por el estilo.