forgery cookie "__RequestVerificationToken" is not present
We have a recently setup a form using umbraco forms. We are using umbraco 7.10.3 and forms 7.0.3. We have elmah.io turned on for this site and we are seeing a few errors namely:
url:/umbraco/RenderMvc, The required anti-forgery cookie "__RequestVerificationToken" is not present
Users of the site have reported getting an error sometimes when submitting this form.
Is this a load balanced scenario? Not specific to umbraco or umbraco forms, but this happens if the response lands on a different server to the request. IIRC there are ways of dealing with it involving machine key configuration. (I may be miles off here)
Assuming its an app service, you are sure the app service plan is set for single instance with no scale out? Because that's exactly what you would see if it wasn't. Turning on ARR affinity might help if it is.
If it isn't, might be worth looking at the logs to see if the instance has been migrated for other reasons - scale up or possibility between hosts might cause the issue. Also code release then VIP swap etc would probably also cause the problem.
Otherwise sorry - I've only seen this with multiple instances.
Did you manage to get to the bottom of this Ismail? We have reports of this on a recently upgraded site as well but in our case it is load-balanced but we do have a custom machineKey shared on all servers so even if they did bounce from one to the other that should not be the cause.
Note: Due to the Load balancer config I don't believe that users should flip-flop between servers during their session so I don't believe that to be related anyway.
Nope support told me to try a few things that didnt work and not heard anything more. This site is not load balanced and we are getting a couple of these errors daily.
Hello Ismail - just a thought (from having seen verification token errors with Forms before) - are these forms rendering from a partial (or macro) that might be cached?
We have had Forms render through a partial that has caching switched on (even 'up the chain', in a parent partial). The cached macro passes the same verification token and when it is submitted it often doesn't match (or is not present). Similar errors get thrown and it wasn't immediately obvious why. Similar to the load-balancing issue but actually a result of cached output on the form.
In my case, it only started occurring when I added something in the web.config.
This line -
I removed this line and it worked again.
Not sure if this will be the same case for you.
It looks like people have already tried this, but we had at least a very similar problem in a load balanced environment and it was because we were missing the machineKey.
forgery cookie "__RequestVerificationToken" is not present
We have a recently setup a form using umbraco forms. We are using umbraco 7.10.3 and forms 7.0.3. We have elmah.io turned on for this site and we are seeing a few errors namely:
Users of the site have reported getting an error sometimes when submitting this form.
Anyone seen this before?
Regards
Ismail
Is this a load balanced scenario? Not specific to umbraco or umbraco forms, but this happens if the response lands on a different server to the request. IIRC there are ways of dealing with it involving machine key configuration. (I may be miles off here)
Andrew,
Site is not load balanced but its sitting on azure so maybe needs machine key?
Regards
Ismail
Assuming its an app service, you are sure the app service plan is set for single instance with no scale out? Because that's exactly what you would see if it wasn't. Turning on ARR affinity might help if it is.
If it isn't, might be worth looking at the logs to see if the instance has been migrated for other reasons - scale up or possibility between hosts might cause the issue. Also code release then VIP swap etc would probably also cause the problem.
Otherwise sorry - I've only seen this with multiple instances.
Auto scale is not supported for the tier that the site is running on.
Regards
Ismail
Did you manage to get to the bottom of this Ismail? We have reports of this on a recently upgraded site as well but in our case it is load-balanced but we do have a custom machineKey shared on all servers so even if they did bounce from one to the other that should not be the cause.
Note: Due to the Load balancer config I don't believe that users should flip-flop between servers during their session so I don't believe that to be related anyway.
Nope support told me to try a few things that didnt work and not heard anything more. This site is not load balanced and we are getting a couple of these errors daily.
Hello Ismail - just a thought (from having seen verification token errors with Forms before) - are these forms rendering from a partial (or macro) that might be cached?
We have had Forms render through a partial that has caching switched on (even 'up the chain', in a parent partial). The cached macro passes the same verification token and when it is submitted it often doesn't match (or is not present). Similar errors get thrown and it wasn't immediately obvious why. Similar to the load-balancing issue but actually a result of cached output on the form.
Hi all,
there is some documentation about the AntiForgeryToken in Forms. Maybe you could check that: https://our.umbraco.com/documentation/Add-ons/UmbracoForms/Developer/Configuration/#enableantiforgerytoken
I have no clue otherwise,
Jeffrey
Jeffrey,
Read that as directed by support does not apply to us. The caching suggestion by Liam will check that further but afaik the from is not cached.
Regards
Ismail
Hi Ismail
In my case, it only started occurring when I added something in the web.config. This line - I removed this line and it worked again. Not sure if this will be the same case for you.
Thanks Rob
Sorry which line?
sorry it has removed the line
Dont have this line in web.config
Robert,
Cool will take a look.
It looks like people have already tried this, but we had at least a very similar problem in a load balanced environment and it was because we were missing the machineKey.
Mark,
We are not load balanced so this it not the issue for us.
Regards
Ismail
is working on a reply...