Le champ obligatoire du formulaire anti-contrefaçon «__RequestVerificationToken» n'est pas présent Erreur lors de l'enregistrement de l'utilisateur


141

J'utilise la Membership.createfonction utilisateur, l'erreur suivante se produit,

Le champ obligatoire du formulaire anti-contrefaçon "__RequestVerificationToken" n'est pas présent

Comment puis-je réparer cela?

Réponses:


218

Vous avez l' [ValidateAntiForgeryToken]attribut avant votre action. Vous devez également ajouter @Html.AntiForgeryToken()dans votre formulaire.


11
J'ai une page Web qui a le même problème mais tout est correct. quelle est l'erreur.
ConduitClever

@ConductedClever Vous devriez vérifier soigneusement tout (champs, cookies) avec Fiddler et / ou Firebug (tous les outils de développement de navigateur), regardez cet article: asp.net/web-api/overview/security/…
webdeveloper

@ConductedClever moi aussi. C'est du travail mais j'obtiens rarement cette erreur et je n'ai aucune idée POURQUOI?
QMaster

J'ai tout ok, dans mes tests ça marche, sur la machine d'un client ça a fonctionné jusqu'à récemment, mais maintenant ça donne cette erreur. Je ne sais pas pourquoi. Quelqu'un a-t-il d'autres idées que celles énumérées ici s'il vous plaît?
Andrei Dobrin

1
Html.AntiForgeryToken();ne marche pas !! Transformer en @Html.AntiForgeryToken()œuvres
FindOutIslamNow

78

Dans mon cas, j'avais ceci dans mon web.config:

<httpCookies requireSSL="true" />

Mais mon projet était configuré pour ne pas utiliser SSL. Commenter cette ligne ou configurer le projet pour toujours utiliser SSL l'a résolu.


3
Dans mon cas, web.config avait requireSSL mais il y avait des liaisons IIS pour les ports 80 et 443, donc les utilisateurs tapant https obtenaient un comportement correct et les utilisateurs tapant http obtenaient cette erreur, mettant dans une règle de réécriture pour forcer tout à https: / / {HTTP_HOST} / {R: 1} corrigé
user1069816

Merci 😃 Dans mon cas, IISil y avait cette liaison ( https » EmptyHostName » IP » 443) mais il n'y avait pas de liaison pour ( https » www.mysite.com » IP » 443). J'ai donc ajouté une nouvelle liaison avec un nom d'hôte non vide pour httpsqui était égal au domaine et cela a résolu le problème. J'ai aussi des paramètres de réécriture IISpour forcer http 2 https.
RAM

61

Comme ça:

Le controlle

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult MethodName(FormCollection formCollection)
{
     ...
     Code Block
     ...
}

La vue:

@using(Html.BeginForm())
{
     @Html.AntiForgeryToken()
     <input name="..." type="text" />
     // rest
}

Essayez d'utiliser uniquement en HTML
Subrata Sarkar

41

Assurez-vous également d'éviter de ne pas utiliser [ValidateAntiForgeryToken] sous [HttpGet].

  [HttpGet]
  public ActionResult MethodName()
  {
  ..
  }

1
Cette réponse a complété les autres et a résolu mon problème! Merci
Lucas

1
Cette réponse suppose que vous n'enregistrez aucune donnée soumise (que vous ne devriez pas être sur un HttpGet). Si tel est le cas, vous avez toujours besoin de la protection XSRF fournie par [ValidateAntiForgeryToken].
thelem

9

Vous recevrez l'erreur même lorsque les cookies ne sont pas activés.


2
Bon coup. J'utilisais Internet Explorer. L'utilisation du navigateur Chrome a résolu le problème pour moi
FindOutIslamNow

Cela a aussi résolu mon problème. activer les cookies dans google chrome. Merci
La méthode scientifique

7

Une autre chose qui peut causer cela (vient de tomber sur ceci) est la suivante: si, pour une raison quelconque, vous désactivez tous vos champs de saisie dans votre formulaire. cela désactivera le champ de saisie masqué contenant votre jeton de vérification. lorsque le formulaire sera renvoyé, la valeur du jeton sera manquante et générera l'erreur qu'il manque. vous devez donc réactiver le champ de saisie contenant le jeton de vérification et tout ira bien.


6

Une autre possibilité pour ceux d'entre nous de télécharger des fichiers dans le cadre de la demande. Si la longueur du contenu dépasse <httpRuntime maxRequestLength="size in kilo bytes" /> et que vous utilisez des jetons de vérification de demande, le navigateur affiche le 'The required anti-forgery form field "__RequestVerificationToken" is not present'message au lieu du message de dépassement de la longueur de la demande.

Définir maxRequestLength sur une valeur suffisamment grande pour répondre à la demande résout le problème immédiat - même si j'admets que ce n'est pas une solution appropriée (nous voulons que l'utilisateur connaisse le vrai problème de la taille du fichier, pas celui des jetons de vérification de la demande manquants).


5

Assurez-vous dans votre contrôleur que vous avez votre attribut http comme:

[HttpPost]

ajoutez également l'attribut dans le contrôleur:

[ValidateAntiForgeryToken]

Dans votre formulaire sur votre vue, vous devez écrire:

@Html.AntiForgeryToken();

J'avais Html.AntiForgeryToken (); sans le signe @ alors qu'il était dans un bloc de code, il n'a pas donné d'erreur dans Razor mais l'a fait au moment de l'exécution. Assurez-vous de regarder le signe @ de @ Html.Ant .. s'il manque ou non


5

Dans mon cas, j'avais ce javascript sur le formulaire de soumission:

$('form').submit(function () {
    $('input').prop('disabled', true);
});

Cela supprimait le RequestVerificationToken masqué du formulaire soumis. J'ai changé cela en:

$('form').submit(function () {
    $('input[type=submit]').prop('disabled', true);
    $('input[type=text]').prop('readonly', true);
    $('input[type=password]').prop('readonly', true);
});

... et cela a bien fonctionné.


Comment avez-vous remarqué que la clé anti-clé affectait lorsque vous désactiviez les entrées?
Cer

1
@Cer - si vous demandez comment j'ai remarqué, j'ai vérifié la demande avec Fiddler et j'ai constaté que la clé n'était pas envoyée. Le J'ai lu que les soumissions Html n'incluront pas les contrôles désactivés. Je l'ai donc changé readonlyet exclu les contrôles cachés. Semble bien fonctionner.
Sean

3

Si quelqu'un rencontre l'erreur pour la même raison pour laquelle je la rencontre, voici ma solution:

si tu avais Html.AntiForgeryToken();

changez-le en @Html.AntiForgeryToken()


2

Dans mon cas, un domaine incorrect dans web.config pour les cookies était la raison:

<httpCookies domain=".wrong.domain.com" />

oui! si vous tapez sur un ordinateur local <httpCookies domain = "localhost" /> alors seuls les cookies de l'ordinateur local fonctionneront et si vous essayez d'ouvrir votre site sur une autre machine, vous entrerez son ip (par exemple 192.168.1.43) qui ne fonctionnera pas car il cherche "localhost"
user3419036

2

Dans mon cas, cela était dû à l'ajout requireSSL=truede httpcookieswebconfig qui a empêché AntiForgeryToken de fonctionner. Exemple:

<system.web>
  <httpCookies httpOnlyCookies="true" requireSSL="true"/>
</system.web>

Pour faire les deux requireSSL=trueet @Html.AntiForgeryToken()travailler, j'ai ajouté cette ligne à l'intérieur du Application_BeginRequestinGlobal.asax

    protected void Application_BeginRequest(object sender, EventArgs e)
  {
    AntiForgeryConfig.RequireSsl = HttpContext.Current.Request.IsSecureConnection;
  }

2

Vous avez cette erreur dans Chrome avec la connexion par défaut pour ASP.NET avec des comptes d'utilisateurs individuels

.cshtml:

@using (Html.BeginForm("Login", "Account", new { ReturnUrl = ViewBag.ReturnUrl }, FormMethod.Post, new { @class = "form-horizontal", role = "form" }))
{
    @Html.AntiForgeryToken()
    <h4>Use a local account to log in.</h4>

Manette:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)

Résolu en effaçant les données du site pour le site:

entrez la description de l'image ici


Ok c'est travaillé. Mais cela se produit encore et encore. Dans Firefox, le même projet fonctionne correctement. Que puis-je faire?
Can Ürek

@ CanÜrek Avez-vous plusieurs projets / sites différents avec le même domaine? Ex localhost, app.site.com et app2.site.com etc.? Cela arrive normalement à cause de cela.
Ogglas

0

Dans ma solution EPiServer sur plusieurs contrôleurs, il y avait un attribut ContentOutputCache sur l'action Index qui acceptait HttpGet. Chaque vue de ces actions contenait un formulaire qui publiait sur une action HttpPost sur le même contrôleur ou sur un autre. Dès que j'ai supprimé cet attribut de toutes ces actions d'index, le problème a disparu.


0

Parce que cela vient avec la première recherche de ceci:

J'ai eu ce problème uniquement dans Internet Explorer et je n'ai pas pu comprendre quel était le problème. En bref, il ne sauvegardait pas la partie cookie du Token car notre (sous) domaine contenait un trait de soulignement. Travaillait dans Chrome mais IE / Edge ne l'aimait pas.


0

Toutes les autres réponses ici sont également valides, mais si aucune d'elles ne résout le problème, il vaut également la peine de vérifier que les en-têtes réels sont transmis au serveur.

Par exemple, dans un environnement à charge équilibrée derrière nginx, la configuration par défaut consiste à supprimer l'en-tête __RequestVerificationToken avant de transmettre la requête au serveur, voir: un simple proxy inverse nginx semble supprimer certains en-têtes


0

Parfois, vous écrivez une méthode d'action de formulaire avec une liste de résultats. Dans ce cas, vous ne pouvez pas utiliser une seule méthode d'action. Vous devez donc avoir deux méthodes d'action avec le même nom. Un avec [HttpGet]et un autre avec [HttpPost]attribut.

Dans votre [HttpPost]méthode d'action, définissez l' [ValidateAntiForgeryToken]attribut et mettez également @Html.AntiForgeryToken()votre formulaire html.


0

Dans mon cas, j'obtenais cette erreur lors de la création d'un message AJAX, il s'est avéré que la valeur __RequestVerificationToken n'était pas transmise dans l'appel. Je devais trouver manuellement la valeur de ce champ et le définir comme propriété sur l'objet de données envoyé au point de terminaison.

c'est à dire data.__RequestVerificationToken = $('input[name="__RequestVerificationToken"]').val();


Exemple

HTML

  <form id="myForm">
    @Html.AntiForgeryToken()

    <!-- other input fields -->

    <input type="submit" class="submitButton" value="Submit" />
  </form>

Javascript

$(document).on('click', '#myForm .submitButton', function () {
  var myData = { ... };
  myData.__RequestVerificationToken = $('#myForm input[name="__RequestVerificationToken"]').val();

  $.ajax({
    type: 'POST',
    url: myUrl,
    data: myData,
    contentType: 'application/x-www-form-urlencoded; charset=utf-8',
    dataType: 'json',
    success: function (response) {
      alert('Form submitted');
    },
    error: function (e) {
      console.error('Error submitting form', e);
      alert('Error submitting form');
    },
  });
  return false; //prevent form reload
});

Manette

    [HttpPost]
    [Route("myUrl")]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> MyUrlAsync(MyDto dto)
    {
        ...
    }

En fait, si vous définissez la structure de votre classe MyDto, ce sera très utile
Chandan Kumar

Eh bien, je ne suis pas sûr que ce sera vraiment très utile et l'exemple de code a disparu depuis longtemps, alors disonspublic class MyDto { public bool Whatever { get; set; } }
demoncodemonkey

-1

Je voudrais partager le mien, j'ai suivi ce tutoriel anti-faux jeton en utilisant asp.net mvc 4 avec angularjs, mais il lève une exception chaque fois que je demande en utilisant $ http.post et j'ai compris que la solution était simplement d'ajouter 'X- Requested-With ':' XMLHttpRequest ' aux en-têtes de $ http.post, car il semble que le (filterContext.HttpContext.Request.IsAjaxRequest()) ne le reconnaisse pas comme ajax et voici mon exemple de code.

App.js

var headers = { 'X-Requested-With': 'XMLHttpRequest', 'RequestVerificationToken': $scope.token, 'Content-Type': 'application/json; charset=utf-8;' };

$http({ method: 'POST', url: baseURL + 'Save/User', data: JSON.stringify($scope.formData), headers: headers }).then(function (values) { alert(values.data); }).catch(function (err) { console.log(err.data); });


SaveController

[HttpPost] [MyValidateAntiForgeryToken] public ActionResult User(UserModel usermodel) { ....

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.