web-dev-qa-db-fra.com

Le jeton anti-falsification n'a pas pu être déchiffré.

J'ai un formulaire:

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
@Html.AntiForgeryToken()
@Html.ValidationSummary()...

et action:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl, string City)
{
}

de temps en temps (une fois par semaine), j'obtiens l'erreur: 

Le jeton anti-falsification n'a pas pu être déchiffré. Si cette application est hébergé par une batterie de serveurs Web ou un cluster, assurez-vous que toutes les machines sont en cours d'exécution même version des pages Web ASP.NET et que la configuration spécifie des clés de chiffrement et de validation explicites. AutoGenerate ne peut pas être utilisé dans un cluster.

j'essaie d'ajouter à Webconfig:

<machineKey validationKey="AutoGenerate,IsolateApps"  
    decryptionKey="AutoGenerate,IsolateApps" />

mais l'erreur apparaît encore parfois

J'ai remarqué que cette erreur se produisait, par exemple lorsqu'une personne venait d'un ordinateur et essayait ensuite un autre ordinateur.

Ou parfois, une valeur automatique définie avec un type de données incorrect, tel que bool to integer au champ de formulaire par un code jQuery, veuillez également la vérifier. 

asp.net-mvcasp.net-mvc-4
46
user3331122

Je viens également de recevoir cette erreur et, dans mon cas, elle est due à l'application du jeton anti-contrefaçon à deux reprises dans le même formulaire. La deuxième instance venait d'une vue partielle et n'était donc pas immédiatement évidente.

114
Steve Dowling

validationKey = "AutoGenerate" 

Cela indique à ASP.NET de générer une nouvelle clé de chiffrement à utiliser pour chiffrer des éléments tels que les tickets d'authentification et les jetons antiforgery à chaque démarrage de l'application. Si vous avez reçu une demande utilisant une clé différente (avant un redémarrage, par exemple) pour chiffrer les éléments de la demande (par exemple, les cookies d'authentification), cette exception peut se produire.

Si vous vous écartez de "AutoGenerate" et le spécifiez (la clé de cryptage) en particulier, les demandes qui dépendent de cette clé doivent être déchiffrées correctement et la validation fonctionnera du redémarrage de l'application au redémarrage. Par exemple:

<machineKey  
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7
               AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"           
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>

Vous pouvez lire le contenu de votre coeur sur la page MSDN: Comment: configurer MachineKey dans ASP.NET

21
Domin8urMind

Générez simplement la balise <machineKey .../> à partir de un lien pour votre version de structure et insérez-la dans <system.web><system.web/> dans Web.config si elle n'existe pas.

J'espère que cela t'aides.

9
logical8

Si Google vous présente cette erreur à partir de google, essayez de supprimer les cookies dans le navigateur. Effacer les cookies du navigateur a fonctionné pour moi.

4
ramons03

J'ai rencontré ce problème dans une zone de code où j'avais une vue appelant une vue partielle. Cependant, au lieu de renvoyer une vue partielle, je retournais une vue.

J'ai changé:

Voir la vue (index);

à 

retourne PartialView (index);

en mon contrôle et cela a résolu mon problème.

3
armstb01

Je reçois cette erreur lorsque la page est ancienne ("périmée"). Une actualisation du jeton via un rechargement de page résout mon problème. Il semble y avoir un certain délai.

1
barrypicker

J'ai eu cette erreur sur .NET Core 2.1. Je l'ai corrigé en ajoutant le service de protection des données dans le démarrage:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection();
    ....
}
1
Cosmin

Si vous utilisez Kubernetes et que vous avez plusieurs pods pour votre application, la validation de la requête échouera probablement car le pod qui génère RequestValidationToken n'est pas nécessairement le pod qui validera le jeton lors de la remise à votre application. Le correctif devrait consister à configurer votre contrôleur nginx ou toute autre ressource d’intrant que vous utilisez et à lui dire d’équilibrer la charge de sorte que chaque client utilise un seul pod pour toutes les communications.

Mise à jour: j'ai réussi à résoudre ce problème en ajoutant les annotations suivantes à mon entrée:

https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/

Name    Description Values
nginx.ingress.kubernetes.io/affinity    Sets the affinity type  string (in NGINX only cookie is possible
nginx.ingress.kubernetes.io/session-cookie-name Name of the cookie that will be used    string (default to INGRESSCOOKIE)
nginx.ingress.kubernetes.io/session-cookie-hash Type of hash that will be used in cookie value  sha1/md5/index
0
PussInBoots