Sto aggiungendo una risposta migliore qui perché questo è un dolore e mal risposto in tutto il web ho pensato di aggiungere le mie soluzioni attualmente lavoro.
Fondamentalmente (ignorando le varie opzioni) AntiForgeryToken funziona aggiungendo un cookie di sessione che viene poi letto quando il modulo viene pubblicato decorando un controller con l'attributo [ValidateAntiForgeryToken].
In primo luogo, prima di procedere alla correzione di qualsiasi cosa, come regola generale, fare sempre quanto segue.
Nel web.config creare una macchinaKey come segue.
<machineKey validationKey="YOUR_KEY" decryptionKey="YOUR_KEY" validation="SHA1" decryption="AES" />
** Nota SHA1 questo non è davvero questo è molto sicuro più ma un'altra discussione **
Google <machineKey> Generator
e configurare.
http://msdn.microsoft.com/en-us/library/w8h3skw9%28v=vs.100%29.aspx
Cambiare il nome del cookie di default da '__RequestVerificationToken' a quella che sarà non essere utilizzato da un'altra applicazione. (Io uso sempre un GUID).
fare questo con AntiForgeryConfig.CookieName = "YOUR_NAME";
Creare un nuovo attributo personalizzato.
Il motivo per questo errore sembra apparire per nessun motivo è che il cookie è valido solo per la vita di una sessione. Per vari motivi, ma soprattutto per il fatto che le persone lasciano le pagine aperte molto molto molto molto tempo la sessione scade. Poiché la sessione è scaduta, il cookie non è più valido.
Un altro problema è che se si dispone dell'attributo [Autorizza] sul postato sul controller, il flusso di elementi genererà HttpAntiForgeryException prima di verificare chi è autenticato. (nella maggior parte dell'autenticazione basata su cookie quando la sessione è scaduta l'utente non è più autenticato)
Il modo per risolvere questo è creare un attributo personalizzato [CustomValidateAntiForgeryToken].
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false, Inherited = true)]
public class CustomValidateAntiForgeryToken : FilterAttribute, IAuthorizationFilter {
public void OnAuthorization(AuthorizationContext filterContext) {
if (filterContext == null) {
throw new ArgumentNullException("filterContext");
}
try {
AntiForgery.Validate();
}
catch {
// Here do whatever is you wish
// you could just re throw the error or what ever.
// In this case I have redirected to a Signout
filterContext.Result = new RedirectToRouteResult(
new RouteValueDictionary(
new {
action = "Sign_Out",
controller = "SOME_CONTROLLER",
area = ""
}
)
);
}
}
}
E, infine, se si cambia tutto questo in qualsiasi sistema attualmente in diretta assicurarsi che tutti si disconnette, si spegne il proprio browser, anche riavvia, se possibile, e cancella i cookie e cache. Si può ancora ricevere l'errore fino a quando non lo si fa per ogni utente anche dopo aver modificato il codice.
Ovviamente le persone hanno esigenze abbastanza diverse, ma si spera che questo dia abbastanza consigli per controllare questo problema molto comune e fastidioso.
Se qualcuno vede qualcosa che aiuti o possa essere aggiunto, per favore fallo.
La roba anti-contraffazione avviene in realtà in "System.Web.WebPages", non in MVC. Quindi dovresti cercare in quella fonte, piuttosto che in MVC. –
Non sono sicuro che AntiForgeryToken abbia qualcosa a che fare con l'utente, in quanto può essere utilizzato indipendentemente dall'autorizzazione. Potrebbe essere legato al tempo. – stevethethread