-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add additional CSRF setting #477
Conversation
omeroweb/settings.py
Outdated
( | ||
"A list of hosts which are trusted origins for unsafe requests. " | ||
"When starting with '.', all subdomains are included. " | ||
"""Example: '[".example.com", "another.example.net"]'""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to SECURE_PROXY_SSL_HEADER
below, might be a good idea to link to the Django documentation for CSRF_TRUSTED_ORIGINS
:
With this PR included on merge-ci I was able to get Django 4.0 working (avoided the CSRF errors I was seeing previously) by setting:
This appears to be a requirement for Django 4.0+ to avoid CSRF errors. Just a thought: would it make sense to hold off on this change until we bump Django to 4.0 (or 4.2) to avoid those upgrade issues? https://docs.djangoproject.com/en/4.0/ref/settings/#csrf-trusted-origins |
I don't really understand why Django 4.0 requires the setting in order for login to work (on merge-ci) but that wasn't needed for Django 3.2. The docs above don't say anything about Django 4.0 being more strict. The only change mentioned for 3.2 -> 4.0 is the addition of the schema to origins. Although we're not the first to see this https://stackoverflow.com/questions/73338124/csrf-token-issue-when-upgrading-django-to-version-4 |
@will-moore do you have a link for the error you were receiving? Scanning quickly the docs, this might be related to the changes described in the CSRF section and bear some relationship with the configuration of the OME CI architecture and the way requests are proxied from |
I'm just seeing the omero-web/omeroweb/feedback/views.py Line 175 in ba072f1
omero-web/omeroweb/settings.py Line 1668 in ba072f1
on login. But yes, that CSRF section of the docs seems to match what we're seeing. It might be nice if |
At least for our systems we have no requirement to set If you are having CSRF errors you'll definitely want to look at the |
Ah - that reminds me that on merge-ci Django doesn't know it is running under |
If that's true then OMERO.web is indeed misconfigured. See also: |
Tried looking into this some more with no luck... I found a couple of examples of others seeing similar issues, but can't tell how to apply their fixes to merge-ci: https://stackoverflow.com/questions/11441832/request-is-secure-always-returns-false-with-uwsgi-server I added an output of the nginx conf on merge-ci, see
which has the line mentioned in one of those posts: |
That's the HTTP rather than HTTPS configuration, no? |
I don't know.
|
@jburel - do you have any idea how It looks like we are already doing:
as suggested fix for this mentions at But reading the warning at https://docs.djangoproject.com/en/3.2/ref/settings/#secure-proxy-ssl-header I don't know if we're satisfying all these conditions on merge-ci. |
@jburel - Thanks for that. I'm not sure exactly what it's doing! Been reading https://realpython.com/django-nginx-gunicorn/ but management_tools and ansible is outside of the scope of that... It seems like this line is relevant:
The nginx config generated by
and this is not configurable since it's in the template:
The setting passed to Django in merge-ci is currently:
I'm not sure if all 3 need to be the same, or if the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is working as expected.
I don't think this PR needs to be held up by the ongoing discussion on merge-ci http vv https since that is not closely related to this setting.
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/release-of-omero-server-5-6-8-and-omero-web-5-22-0/84157/1 |
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/docker-image-of-omero-web-5-23-0-still-with-v5-22-1/88699/13 |
Following #471, this PR adds another required setting to make CSRF requests work:
Without this setting, it is not possible to perform cross-domain unsafe HTTP requests (
POST
,PUT
, andDELETE
), even if cookies etc. are configured correctly.Reference: