Anti forgery token jest przeznaczony dla użytkownika"", ale aktualnym użytkownikiem jest " username"

Aby naprawić błąd, należy umieścić adnotację OutputCache na stronie Get ActionResult logowania jako:

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

Zdarza się to wiele razy z moją aplikacją, więc postanowiłem ją wygooglować!

Znalazłem proste wyjaśnienie tego błędu! Użytkownik klikając dwukrotnie przycisk logowania! Możesz zobaczyć inny użytkownik mówiący o tym na poniższym linku:

MVC 4 pod warunkiem, że Token anti-forgery był przeznaczony dla użytkownika"", ale aktualnym użytkownikiem jest "user"

Mam nadzieję, że to pomoże! =)

Miałem ten sam problem, i ten brudny hack go naprawił, przynajmniej dopóki nie będę mógł naprawić go w czystszy sposób.

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

...

Miałem dość specyficzny, ale podobny problem w procesie rejestracji. Po kliknięciu łącza e-mail wysłanego do niego, użytkownik zostanie zalogowany i wysłany bezpośrednio do ekranu szczegółów konta, aby podać więcej informacji. Mój kod to:

    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

Odkryłem, że Widok powrotu ("AccountDetails") dawał mi wyjątek token, zgaduję, ponieważ funkcja ConfirmEmail była ozdobiona AllowAnonymous, ale funkcja AccountDetails miała ValidateAntiForgeryToken.

Zmiana Return Na Return RedirectToAction ("AccountDetails") rozwiązała problem.

Mam ten sam wyjątek występujący najczęściej na serwerze produkcyjnym.

Dlaczego tak się dzieje?

Dzieje się tak, gdy użytkownik loguje się z ważnymi poświadczeniami i po zalogowaniu i przekierowaniu na inną stronę, a po naciśnięciu przycisku Wstecz wyświetli stronę logowania i ponownie wprowadził ważne poświadczenia, że czas ten wyjątek wystąpi.

Jak rozwiązać?

Po prostu dodaj tę linię i pracuj idealnie, Nie uzyskaj błędu.

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

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

public ActionResult Login(string returnUrl)

Możesz to przetestować, umieszczając punkt przerwania w pierwszej linii działania Login (Get). Przed dodaniem dyrektywy OutputCache punkt przerwania zostanie trafiony przy pierwszym ładowaniu, ale po kliknięciu przycisku Wstecz przeglądarki nie będzie. po dodaniu dyrektywy powinieneś skończyć z punktem przerwania za każdym razem, więc AntiForgeryToken będzie rdzeniem, a nie pustym.

Miałem ten sam problem z jedną stroną ASP.NET aplikacja MVC Core. Rozwiązałem to ustawiając HttpContext.User we wszystkich akcjach kontrolera, które zmieniają bieżące roszczenia tożsamości (ponieważ MVC robi to tylko dla kolejnych żądań, jak omówiono tutaj). Użyłem filtra wyników zamiast oprogramowania pośredniczącego do dołączania plików cookie do moich odpowiedzi, co upewniło się, że zostały one wygenerowane dopiero po powrocie akcji MVC.

Kontroler (NB. Zarządzam użytkownikami z ASP.NET Rdzeń "Tożsamość": {]}

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

Filtr wynikowy do dołączania plików cookie:

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 ekstrakt:

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

Wiadomość pojawia się po zalogowaniu, gdy jesteś już uwierzytelniony.

Ten Helper robi dokładnie to samo co atrybut [ValidateAntiForgeryToken].

System.Web.Helpers.AntiForgery.Validate()

Usuń atrybut [ValidateAntiForgeryToken] z kontrolera i umieść ten helper w action methode.

Więc gdy użytkownik jest już uwierzytelniony, przekierować do strony głównej lub jeśli nie kontynuować weryfikację ważnego tokenu anty-forgery po tej weryfikacji.

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

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

Aby spróbować odtworzyć błąd, postępuj jak następuje: Jeśli jesteś na stronie logowania i nie jesteś uwierzytelniony. Jeśli zduplikujesz kartę i logujesz się za pomocą drugiej karty. A jeśli wrócisz do pierwszej Zakładki na stronie logowania i spróbujesz się zalogować bez przeładowywania strony ... masz ten błąd.

Ma problem z anti-forgery-token validation w sklepie internetowym: użytkownicy otwierają wiele zakładek (z towarami) i po zalogowaniu się na jednym próbują się zalogować na drugim i dostają takie AntiForgeryException. Więc, AntiForgeryConfig.Suppressidentitiheuristicchecks = true nie pomogło mi, więc użyłem takiego brzydkiego hackfixa, może komuś się przyda:

   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());
    }
}

Myślę, że będzie świetnie, jeśli Opcje anti-forgery-token generation można ustawić, aby wykluczyć nazwę użytkownika lub coś w tym stylu.