Le champ "RequestVerificationToken" du formulaire anti-falsification requis n'est pas une erreur dans L'inscription de l'utilisateur

dans mon cas, j'avais ça sur ma toile.config:

<httpCookies requireSSL="true" />

mais mon projet ne devait pas utiliser SSL. Commenter cette ligne ou configurer le projet pour toujours utiliser SSL résolu.

comme ceci:

Le Contrôleur

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

Le Point De Vue:

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

également, assurez-vous d'éviter d'utiliser [ValidateAntiForgeryToken] en vertu de [HttpGet].

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

vous recevrez l'erreur même si les Cookies ne sont pas activés.

une autre chose qui peut causer ceci (vient de tomber sur ceci) est la suivante: si vous désactivez tous vos champs de saisie dans un formulaire. il désactivera le champ d'entrée caché qui contient votre token de vérification. lorsque le formulaire sera retourné la valeur du jeton sera absent et va générer l'erreur qu'il est manquant. donc, ce que vous devez faire est de réactiver le champ d'entrée qui contient le jeton de vérification et tout ira bien.

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 , vous utilisez des jetons de vérification de la demande, le navigateur affiche le message 'The required anti-forgery form field "__RequestVerificationToken" is not present' au lieu du message de dépassement de la longueur de la demande.

mettre maxRequestLength à une valeur assez grande pour répondre à la demande guérit la question immédiate-bien que je dois admettre que ce n'est pas une solution appropriée (nous voulons que l'utilisateur à connaître le vrai problème de la taille du fichier, pas celui des tokens de vérification de requête manquants).

assurez-vous dans votre controller que vous avez votre attribut http comme:

[HttpPost]

ajouter aussi l'attribut dans le contrôleur:

[ValidateAntiForgeryToken]

dans votre forme sur votre vue vous devez écrire:

@Html.AntiForgeryToken();

J'avais Html.AntiForgeryToken (); sans le signe @ pendant qu'il était dans un bloc de code, il n'a pas donné une erreur dans Razor mais a fait à l'exécution. assurez-vous de regarder le signe @ de @Html.Fourmi.. si c' est manquant ou non

dans mon cas, j'avais ce javascript sur le formulaire soumettre:

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

cela supprimait la vérification derequête cachée du formulaire soumis. J'ai changé ça en:

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

... et il a bien fonctionné.

si quelqu'un fait l'expérience de l'erreur pour la même raison que moi, voici ma solution:

si vous aviez Html.AntiForgeryToken();

changer pour @Html.AntiForgeryToken()

dans mon cas, domaine incorrect dans web.config for cookies était la raison:

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

dans ma solution D'EPiServer sur plusieurs controllers, il y avait un attribut ContentOutputCache sur L'action Index qui acceptait HttpGet. Chaque vue pour ces actions contenait un formulaire qui affichait une action HttpPost vers le même contrôleur ou vers un contrôleur différent. Dès que j'ai enlevé cet attribut de toutes ces actions Index problème était parti.

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

j'ai eu ce problème seulement dans Internet Explorer et ne pouvait pas comprendre ce qu'était le problème. Pour faire court, il ne s'agissait pas de sauvegarder la partie cookie du Token car notre (sous)domaine y avait un underscore. Travaillé en Chrome mais IE / Edge n'a pas aimé.

Toutes les autres réponses ici sont également valables, mais si aucun d'entre eux de résoudre le problème, il est également utile de vérifier que les en-têtes sont transmises au serveur.

par exemple, dans un environnement de charge équilibrée derrière nginx, la configuration par défaut est de supprimer l'en-tête _ _ RequestVerificationToken avant de passer la requête sur le serveur, voir: simple NGINX reverse proxy seems to strip some headers

j'aimerais partager le mien, j'ai suivi ce tutoriel anti forgerytoken utilisation asp.net mvc 4 avec angularjs, mais il lance une exception chaque fois que je demande en utilisant $http.post et j'ai trouvé la solution est simplement d'ajouter 'X-requested-with': 'XMLHttpRequest' pour les en-têtes de $http.post, parce qu'il semble comme le (filterContext.HttpContext.Request.IsAjaxRequest()) ne la reconnaît pas comme ajax et voici mon code d'exemple.

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