Try our conversational search powered by Generative AI!
AI OnAI Off
Forms - sometimes get error about "Failed to validate the anti-forgery token"
Ok a bit more info after investigating.
It turns out sometimes when the page loads the __RequestVerificationToken cookie is missing along with .EPiForm_BID and .EPiForm_VisitorIdentifier.
The tag <input name="__RequestVerificationToken" type="hidden" value=""/> when the cookie is missing always has the same token value. So the clue might be there, possible caching maybe?
Sep 19, 2018 10:05
It's on the DXC cloud environment.
I have confirmed it's the output cache of the page doing it.
If you load a cached version of the page, the form will not create the cookies required.
Sep 19, 2018 12:08
I have the same issue. When I have ContentOutputCache attribute present on a page-controller that has a form on the page the value in the form field "__RequestVerificationToken" is never updated.
Steps to reproduce:
- Set the [ContentOutputCache] on the current page controller.
- Restart the site (clear all cache)
- Visit the page with the form in one browser and send the form (this works fine)
- Visit the age in another browser and try posting the form (this fails)
The value in the hidden input "__RequestVerificationToken" are the same in both browsers. The sesison cookie value differs between the browsers and this is causing the comparison of the two to fail.
Im running Episerver 11.9.3, with Forms version 4.15.1, no custom FormContainerBlock.ascx.
Is there a way to force the input value to update but still have the ContentOutputCache enabled?
Edited,
Oct 02, 2018 10:22
The only way I got around it was to force the form to not cache the page. So I added this to the FormContainerBlock.ascx
<% //Expire page cache fix for form output caching on the page causing cookies to not be generated.
HttpContext.Current.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
HttpContext.Current.Response.Cache.SetValidUntilExpires(false);
HttpContext.Current.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
HttpContext.Current.Response.Cache.SetNoStore();
%>
Oct 02, 2018 10:26
Ok, that's bad news for me since we have a contact-form on all pages... I guess that means I have to skip the Outputcache.
It's weird though, because I have only noticed this issue after we upgraded to Episerver 11.x, maybe there were some changes to how the tokens are generated?
Oct 02, 2018 10:35
I just found that the code on teh form page that generates the cookies just never fires as the whole form container is cached. If there's a way to keep it cached and still clear those cookies then that would be good! I guess maybe some javascript might be able to delete them as that would always fire regardless of page caching. The problem is the __RequestVerificationToken is a http cookie so I couldn't get to it via javascript to manipulate it.
Oct 02, 2018 10:39
Yes that changed on Episerver 11. I had to add
<%= Html.GenerateAntiForgeryToken(Model) %>
to my form container as they'd changed theirs.
Oct 02, 2018 10:40
I have a form which has received 100s of successful submissions. However we are also getting some of these errors too:
,"EPiServer.Forms.Internal.Security.DefaultAntiForgeryValidator : Failed to validate the anti-forgery token
System.Web.Mvc.HttpAntiForgeryException (0x80004005): The required anti-forgery cookie ""__RequestVerificationToken"" is not present.
at System.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken)
at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext, String cookieToken, String formToken)
at EPiServer.Forms.Internal.Security.DefaultAntiForgeryValidator.Validate(HttpContextBase httpContext)",
I can't make the form ever go wrong when I test it. The value is always there when I view the source:
I have a version of the FormContainerBlock.ascx file here
\Views\Shared\ElementBlocks\FormContainerBlock.ascx
It has the correct entry - which I had to add after upgrading months ago.
<%= html.generateantiforgerytoken(model) %>
Anyone come across this? Obviously if the code was wrong it would fail all the time.....