nginx w/wagtail hits django 4.x CSRF block on admin site
Amondale opened this issue · 4 comments
with nginx as a frontend to bakerydemo, I give credentials to admin login page, then I get:
Forbidden (403)
CSRF verification failed. Request aborted.
Help
Reason given for failure:
Origin checking failed - https://wag.test does not match any trusted origins.
I added the following line to base.py in bakerydemo/setttings:
CSRF_TRUSTED_ORIGINS = ['https://wag.test']
Anybody seen this, or know a solution? I think the issue started with Django 4.x, haven't seen it before.
TIA,
Alex
I suspect this has to do with https://docs.djangoproject.com/en/4.0/releases/4.0/#csrf
It is very much a Django feature, rather than Wagtail/bakerydemo.
Will mark this as closed. Best to continue the discussion the #support channel on Slack
I suspect this has to do with https://docs.djangoproject.com/en/4.0/releases/4.0/#csrf
It is very much a Django feature, rather than Wagtail/bakerydemo.
Will mark this as closed. Best to continue the discussion the #support channel on Slack
Think I saw a similar issue raised around the gitpod implementation, now that django 4.x is in the requirements.txt, and gitpod requires TLS/SSL, which is where this CSRF issue is coming from. Not sure why it would be so hard to put the required header notation in Wagtail, I will raise the issue in that GH area, you're right it isn't "bakerydemo-specific."
Not sure why it would be so hard to put the required header notation in Wagtail,
It is not that hard. At the same time there are about a million other non hard things to do, alongside harder, more pressing issues :)
Having said that, CSRF_TRUSTED_ORIGINS is something the developer should control. While we can add the header (probably based on the Site entries), there are plenty of edge cases to cover that frankly make this less apealling in that it will increase the maintenance burden. Say what if you pull the staging or production database which has different hostnames?
In my opinion, this is a documentation issue. 🤔
Not sure why it would be so hard to put the required header notation in Wagtail,
It is not that hard. At the same time there are about a million other non hard things to do, alongside harder, more pressing issues :)
Having said that,
CSRF_TRUSTED_ORIGINSis something the developer should control. While we can add the header (probably based on the Site entries), there are plenty of edge cases to cover that frankly make this less apealling in that it will increase the maintenance burden. Say what if you pull the staging or production database which has different hostnames?In my opinion, this is a documentation issue. 🤔
All very good points; I noticed a simple workaround was to access the site over http: which doesn't have CSRF exposure, but does have privacy and MITM concerns. Weird that inserting the CSRF_TRUSTED_ORIGINS into the settings/base.py file didn't solve the issue, so I still feel it might be a Wagtail v. Django misunderstanding rather than a doc issue. Django 4.0 did change the style for that insertion (see this 4.0 doc entry)