This project is read-only.

The required anti-forgery form field "__RequestVerificationToken" is not present.

Topics: Core, Customizing Orchard, Writing modules
Jan 6, 2015 at 11:35 AM
Edited Jan 6, 2015 at 11:37 AM
I am calling my custom controller action through a jquery ajax method. I have already tried including the antiforgeryToken to the my jsonObject and I can also see in FireFox FireBug that the antiforgery token is sent in my POST request as well, but due to some reason the Orchard does not get this token and throws the exception.

Here is json object which is sent via ajax call
 "contentItemId": 10,  
 "returnUrl"    : "http://localhost:30321/OrchardLocal/Admin/Contents/Edit/10",
The Exception occurs in class AntiForgeryAuthorizationFilter.cs on line Validator.OnAuthorization(filterContext);

The Rest of the Code is Very Simple

<a href="javascript:void(null);" title="OK" onclick="SubmitContent('@url', @Model.ContentItem.Id, '@Request.Url.AbsoluteUri')">@T("OK")</a>
jQuery Methods
        function SubmitContent(url, contentItemId, returnUrl) {

            var jsonObject = {
                "contentItemId": contentItemId,
                "returnUrl": returnUrl

            jsonObject = AddRequestVerificationToken(jsonObject);

                url: url,
                type: "POST",
                data: JSON.stringify(jsonObject),
                contentType: "application/json; charset=utf-8",
                dataType: "json",
                success: function (data) {
                    // Do something here

        function AddRequestVerificationToken(data) {
  //data.__RequestVerificationToken = $('input[name=__RequestVerificationToken]').val();
  data.__RequestVerificationToken = "@Html.AntiForgeryTokenValueOrchard()";

            return data;
 public ActionResult UserAction(UserInputParams userInputParams)
    return ....  
Jan 6, 2015 at 2:42 PM
And are you sure that in the end the POST data will contain __RequestVerificationToken in exactly the same way as it is when posting a standard form? I.e. there is nothing that results in a difference after the json-stringify process?
Jan 7, 2015 at 8:57 AM
Edited Jan 7, 2015 at 9:05 AM
Yes. Both the Tokens are same. I have cross checked both the tokens. One that is generated by the orchard and is present in the source of the page rendered, and the one which you can see using FireBug in POST request, are same

BUT the one which is generated in the Request Headers section is very different and very long.

Verification Token Generated on Page Rendered:
Verification Token Generated in Header Request:
   "__RequestVerificationToken_L09yY2hhcmRMb2NhbA2=fV2yW62NgOT4WYToPAPfJCPfrJbl-nQCMetHtiOcGyAJrCS8eFrZHHXC_c0fkO1ik5BO03Mb0fTSxAk_xiHQ4n5hJs2n4lbntrgEinom3S41; .ASPXAUTH=5C20AD4F78A751864D2B45AB6861302CAAEA0944C7300C6B5D92DEF789E3F50DFEC26763771144254C37B8566B9E0113E47364852C6A0409792075D3206F3F6B9B033B07EFF71649E7C616B5D6FBE2D38D4956C2E734994907BA48BEE93B44F09737067384714E866D7AF298EA99DD06"
And Also, the one which is generated through Html.VerficationRequestTokenValueOrchard() method is also different. I have tried sending the token generated by this method, but it also gives the same exception.

Jan 7, 2015 at 11:51 AM
I found the culprit at last. I have made the following changes to my Ajax method at it is working all fine now:
                url: url,
                type: "POST",
                data: jsonObject,                
                dataType: "json",
                success: function (data) {
                    // Do something here
As you noticed, I have removed the contentType property from this ajax call. I have also removed JSON.Stringfy() method.

Still don't understand why it was causing the exception. But it has solved the problem. And I am very happy for it.

Marked as answer by cloudsurfer on 1/7/2015 at 3:51 AM
Jan 7, 2015 at 11:54 AM
That's why I asked whether the POST data contains the token in the same way as with normal forms. My guess would be that it didn't: the token filter looks for a specific POST field and it couldn't find it for your request, indicating that it was sent differently.
Marked as answer by cloudsurfer on 1/8/2015 at 10:52 PM
Jan 9, 2015 at 6:54 AM
Yes. You are right.