Unable to verify your data submission.

[piotrpog]

This message sometimes appear when i try to save something, for example save entry, add field, install plugin etc:

HTTP 400 – Bad Request – yii\web\BadRequestHttpException Unable to verify your data submission.

It appears seemingly at random, sometimes it does, sometimes it doesnt.

I noticed this on my windows based craft install. Craft cms install itself seems somehow corrupted, because i also have other craft install on this machine, without such problems. This is my system info:

PHP version 7.2.2
Database driver & version MySQL 5.5.5
Image driver & version GD 7.2.2
Craft edition & version Craft Solo 3.0.25
Yii version 2.0.15.1
Twig version 2.5.0
Guzzle version 6.3.3
Imagine version 0.7-dev

[brandonkelly]

That error occurs when the posted CSRF token param doesn't match the one in the CSRF cookie.

Can you try using a different browser and see if that helps? Or clear all cookies in your current browser.

[piotrpog]

I switched browsers and problem disappeared indeed.

[brandonkelly]

Is Chrome the problematic browser, by chance? If so we’ve seen issues with that if the site was accessed via https at one point, but now you’re back on http.

[piotrpog]

Yes, it was Chrome. But im not sure if i ever accessed site by https.

[piotrpog]

@brandonkelly
Today i installed second install of craft on my xampp localhost. And I started getting these errors again.

Im positive it has nothing to do with https. It seems that these two craft installs somehow conflict with each other, when im logged to both controll panels, possibly because they use same domain (localhost).

[brandonkelly]

@piotrpog Yeah if you have two installs running from the same hostname (localhost), and you have both open at the same time in the same browser, their cookies could conflict with each other.

[piotrpog]

@brandonkelly so, it is expected behaviour? It is little inconvenient for some webdevs that work on multiple sites and have single local web server set up.

[brandonkelly]

@piotrpog It’s not preferable but not sure what Craft can do about it either. You can work around it by setting up multiple local host names (e.g. site1.test, site2.test, etc.) rather than accessing everything through localhost.

[intoeetive]

I have expirienced the same issue, but not just on localhost, also on dev server.
I noticed that on each each page load Craft is calling index.php?p=actions/queue/run so I disabled runQueueAutomatically in config.php and that seems to have fixed the issue. Could it be that task runner is invalidating the security token?

[simeon-smith]

I got this error and checked my error log. I found a bunch of errors like this:

2019-01-18 09:03:30 [-][-][soundnpevuons07lqg8c911grb][error][yii\base\ErrorException:2] yii\base\ErrorException: fopen(/craft/web/cpresources/725d4d8/jquery-ui.min.js): failed to open stream: No such file or directory in /craft/vendor/yiisoft/yii2/web/Response.php:485.

When researching I found that there might be some write issue errors with the sub folders of the /web/cpresources folder. I cleared out all the sub folders and then tried to log in again. Now it all works.

[amityweb]

I have a front end form to log users in, and I often get this issue when accidentally clicking the Login button a second time when logging in. If I click it once it logs in OK, but if I click it again before the first login occurs I get this error. Hitting refresh still shows the error. If I just reload the page (not resubmitting the form when you refresh) I am logged in.

So I guess its something to do with the CSRF on the second form submission, maybe because the first logged me in already.

Eitherway, its not very professional to have our end users experience this but have no idea how I can fix it.

Any suggestions to avoid this or should it be addressed in the core code?

Thanks

[brandonkelly]

@amityweb The Control Panel’s login page shouldn’t allow you to double-click on it. If that’s where you’re seeing this, then please file a separate issue about it.

If you‘re seeing this on a front-end login form, yeah that is to be expected because the CSRF token will change as soon as the user is logged in. Nothing Craft can do at a system level to prevent you from initiating two separate login requests; you’ll just have to add your own JavaScript to disable the button once the form has been submitted the first time.

Related – if you are submitting the login request over Ajax, as of Craft 3.1.13 the new CSRF token is actually included in the response, which you can use to avoid CSRF issues on future Ajax requests. (Thanks to PR #3860.)

[amityweb]

OK this then "you’ll just have to add your own JavaScript to disable the button once the form has been submitted the first time." -> probably be good to have this page needs some explanation https://docs.craftcms.com/v3/dev/examples/login-form.html else we just copy the code and wonder why it doesn't work! Thanks

[brandonkelly]

@amityweb Realized we could guard against this on Craft’s end with a little exception to the users/login action. Now when you hit that, if someone is already logged in, it will stop enforcing CSRF validation, and allow Craft to go forward with redirecting the user as if they had just successfully logged in. So this won’t be an issue as of the next release.

[amityweb]

I have one front end user get this on an Activation link. Shall I open a new issue? Didn't know if its related. So an Admin adds a user, user gets the activation link, they click the link in the email, and see this message right away. Most users it works OK, but this one reported the issue. i dont know where to start! Thanks

[brandonkelly]

@amityweb Any chance they’re already logged in on another account at the time?

[MichaelCaraccio]

I had the same problem after updating the version of Craftcms (up to 3.1.15) from cli.

To make it works again, I had to use the clearcache command line...

[amityweb]

@amityweb Any chance they’re already logged in on another account at the time?

Cant see how they would, this is the first email sent to them when the admin added them, so the first activation link sent to them.

Can the system not check various reasons and show a better explanation? e.g. "you are already logged in" or "cookies disabled" (or if there is anything that prevents sessions working), or something else that could indicate the reason?

[brandonkelly]

@amityweb Actually this doesn’t make any sense. Craft only ever checks CSRF tokens on POST requests, not GET. And clicking on a link in email is just going to give you a GET request.

Maybe ask that user to send you the link. Then ensure you’re logged out, and go to the link. Are you able to reproduce the error? If so please empty out your storage/logs/ folder, reproduce the error again, and then search for the error in storage/logs/web.log, and post the stack trace that follows it.

[amityweb]

@amityweb Actually this doesn’t make any sense. Craft only ever checks CSRF tokens on POST requests, not GET. And clicking on a link in email is just going to give you a GET request.

Maybe ask that user to send you the link. Then ensure you’re logged out, and go to the link. Are you able to reproduce the error? If so please empty out your storage/logs/ folder, reproduce the error again, and then search for the error in storage/logs/web.log, and post the stack trace that follows it.

Ok so maybe an issue not do with CSRF and something else, shall i create a new issue? I did click the link but it said it expired for me now. When I created a new user which sent the email to me, it all worked. Its always worked for me and other users. It was just this one new user which is making it hard to find the issue!

I'll double check with the customer again also, because there could also be something inaccurate in their explanation! Leave it for now, I will raise a new issue if it continues to happen, and look in logs. I thought it may be related due to the same error is all. Thanks.

[brandonkelly]

Yeah so I guess you’ll just need to work with them to reproduce it, and then make sure you catch the exact steps they took, and the exact error message that occurred, and then track that error down in your logs. Once you do, please post as a new issue. Even if it’s CSRF related, it’s probably unrelated to the scenario that this issue was posted about.

[jayhlee]

I'm getting a CSRF issue using the Wheelform plugin (yii\web\HttpException:400). It seems the problem is actually stemming from Craft rather than the plugin because the trace isn't making it to the plugin controllers. Here's my stacktrace:

yii\web\BadRequestHttpException: Unable to verify your data submission. in /srv/users/sp/apps/acme/vendor/yiisoft/yii2/web/Controller.php:166

Stack trace:
#0 /srv/users/sp/apps/acme/vendor/craftcms/cms/src/web/Controller.php(88): yii\web\Controller->beforeAction(Object(yii\base\InlineAction))
#1 /srv/users/sp/apps/acme/vendor/yiisoft/yii2/base/Controller.php(155): craft\web\Controller->beforeAction(Object(yii\base\InlineAction))
#2 /srv/users/sp/apps/acme/vendor/craftcms/cms/src/web/Controller.php(109): yii\base\Controller->runAction('send', Array)
#3 /srv/users/sp/apps/acme/vendor/yiisoft/yii2/base/Module.php(528): craft\web\Controller->runAction('send', Array)
#4 /srv/users/sp/apps/acme/vendor/craftcms/cms/src/web/Application.php(297): yii\base\Module->runAction('wheelform/messa...', Array)
#5 /srv/users/sp/apps/acme/vendor/craftcms/cms/src/web/Application.php(561): craft\web\Application->runAction('wheelform/messa...', Array)
#6 /srv/users/sp/apps/acme/vendor/craftcms/cms/src/web/Application.php(281): craft\web\Application->_processActionRequest(Object(craft\web\Request))
#7 /srv/users/sp/apps/acme/vendor/yiisoft/yii2/base/Application.php(386): craft\web\Application->handleRequest(Object(craft\web\Request))
#8 /srv/users/sp/apps/acme/public/index.php(42): yii\base\Application->run()
#9 {main}

When CSFR is disabled, the form works. Any help would be greatly appreciated!

[brandonkelly]

@jayhlee steps 0-2 there are taking place on the Wheelform controller, just via its base classes. I’d definitely start with looking at the plugin.

[stenvdb]

I get this error on frontend forms (in my case not related to logging frontend users in). I've had this now in both the Contact Form plugin (craftcms/contact-form#150 (comment)) and also with Freeform. It is the exact same error as described, by for example @jayhlee. The stack trace is identical, line #4 and #5 happen in some plugin indeed (so in @jayhlee's case wheelform), I have seen it happen in both freeform and contact-form. So that's the exact same error in 3 plugins. The other lines in the stack trace are identical. I submit my forms with axios, for example:

axios.post(path, new FormData(form), {
    headers: { 'X-Requested-With': 'XMLHttpRequest' },
})

My issue is somehow resolved after logging into the cms with my admin user and logging back out. But after some time there is something that triggers the error to re-appear. I have no idea what. I've seen it happen only in online staging / production environments, not on my local install. Any help would be greatly appreciated.

Edit: 99% sure my issue was some caching so that the template was displaying the wrong csrf cookie.

[brandonkelly]

@stenvdb The CSRF token is recycled any time a user logs in or out, so you will need to make sure that the JS is kept updated with that. (Since Craft 3.1.13, users/login and users/logout actions now include a csrfTokenValue key in JSON responses.)

[stenvdb]

Thanks @brandonkelly, so makes sense when submitting (especially with ajax) to fetch a new token just before the submit. That might clear up some issues. I think my issue is the token in my template {{ csrfInput() }} is getting cached sometimes.. somehow.. I'm mailing with support@craftcms.com they're helping me find the culprit.

[Kimixi]

What worked for me was changing the data encoding. Try changing serialize() to new FormData() when you are submitting the form with ajax.

Small example:

    // const formData = this.$form.serialize();
    const formData = new FormData(this.form);

    Request
        .post(this.formAction, formData)
        .then(result => this.successFormHandler(result))
        .catch(error => this.errorFormHandler(error));

[controlnocontrol]

I was having the same issue on one of my clients' live server and think I figured out the issue for those inserting the CSRF code in the template using csrfInput(). Caching the templates was the cause and the token was being cached as well, causing the 400 error. Just make sure that your contact form (or CSRF output to be precise) isn't found in a cache block. @brandonkelly is it possible to tweak the output code on your end to make sure that the CSRF code is never cached?

[controlnocontrol]

@stenvdb if your contact form is added via includes, check if the parent files have any cache blocks.

[iamkeir]

@ohbiko thanks for this - we were having intermittent/random 400 errors but couldn't seem to find any consistency of cause. Then noticed we had some {{ csrfInput() }} within {% cache %} blocks.

Also found reference to this in the {% cache %} docs:

Since the cache tag is for caching output and not logic, avoid caching {{ csrfInput() }}, form fields, or parts of templates where dynamic output is expected.

@brandonkelly is it possible to tweak the output code on your end to make sure that the CSRF code is never cached?

I'd also be interested if this could somehow be cache-exempt.

Worth adding the note about not caching {{ csrfInput() }} to this page, too?
https://craftcms.com/knowledge-base/enabling-csrf-protection

[mattstein]

Added a note to that Knowledge Base article, thanks @iamkeir!

[delasign]

If this is regarding a Craft API or controller action, I solved it by disabling the csrfvalidation for the specific controller and action.

Details can be found here:
https://delasign.com/blog/craft-cms-api/

[khalwat]

@piotrpog Yeah if you have two installs running from the same hostname (localhost), and you have both open at the same time in the same browser, their cookies could conflict with each other.

Is there a way around this @brandonkelly ? I frequently have multiple Craft sites open hanging off of localhost, running on different ports.

Is there any settings that could be overridden in Craft to mitigate this? Perhaps I can set csrfTokenName to the CRAFT_APP_ID (assuming it's unique)

[khalwat]

For anyone else who is stumbling across this, what I mention above does indeed work:

    // Use a unique CSRF token name, to avoid issues with CSRF validation with multiple instances of
    // Craft running on the same host (localhost)
    ->csrfTokenName(App::env('CRAFT_APP_ID'))

...where CRAFT_APP_ID is unique on a per-site basis

https://github.com/nystudio107/spin-up-craft/blob/master/config/general.php#L30

[BenMenking]

We ran into the "unable to verify data submission" and it turned out that someone set the "defaultCookieDomain" in config/general.php to ".ddev.site" which broke any environment not using .ddev.site as a domain.

[Abdulkadiragoliya]

You just need to add the jquery code.

jQuery(document).ready(function(){
fetch("/actions/blitz/csrf/token").then(e=>e.text()).then(e=>{$('[name="CRAFT_CSRF_TOKEN"]').val(e)})
});