2

First of all the control panel login is unstyled, and I'm getting Bad Request Unable to verify your data submission when trying to login to the control panel. I can login using a form on the front end, but then I find the CP is still unstyled. Using console I can see the cpresources files cannot be found by the browser - but I've checked they are there, and have file permissions set.

Any ideas???

Improve this question
1
  • In my case I had a module uploading large files to s3, it got fixed after tweaks on upload_max_filesize, post_max_size and max_execution_time. One can get sidetracked by the CSRF error, but it was actually execution timeout.
    – Leo Leoncio
    Commented Aug 19, 2021 at 0:57

5 Answers 5

Reset to default
4

There isn't really enough information here to give a full answer, but 'Bad Request Unable to verify your data submission' means that Craft is not getting supplied the correct CSRF token.

To confirm, try turning off CSRF protection in your config: https://craftcms.com/docs/3.x/config/config-settings.html#enablecsrfprotection

Improve this answer
1
  • I don't quite understand what is going on, but I turned off CSRF protection, then changed the cpresources to 774 all is OK. I then removed CSRF protection false from the config and still OK. (So marking your answer correct for that reason!)
    – Andrew
    Commented Sep 30, 2020 at 7:18
2

It's an old question, but since I keep coming back and using the answers, I'll add a bit. From time to time it seems after an update I have trouble like this. Fixing the permissions on craft/storage solves it for me.

~/craft$ chmod -R 774 storage

From the Craft3 docs:

For Craft to run properly, PHP needs to be able to write to the following places:

.env
composer.json
composer.lock
config/license.key
config/project/*
storage/*
vendor/*
web/cpresources/*

The exact permissions you should be setting depends on the relationship between the system user that runs PHP and whoever owns the folders and files.

  • If they’re the same user, use 744.
  • If they’re in the same group, use 774.
  • If you’re not sure and enjoy life on the edge, use 777.
Improve this answer
1

Can you please check if CP tries to load resources (js, css) via http:// but the CP itself is loaded via https://?

If that’s the case then you have a mixed content problem, which could be caused by a wrong protocol (http by https) in your site_url setting in .env

Improve this answer
1

In my case i just deleted everything inside the cpresources folder

rm -rf ./web/cpresources

Improve this answer
0

I replaced cpresources from the dev environment with the original backup, and got going again. The reason seemed to be permissions - cpresources worked with 705, but not with 774.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.