You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
USE_X_FORWARDED_HOST = True is not needed when running RDMO in Apache so we should not add it to RDMO by default. I think we should add it to rdmo-app and document it properly, but there could be some inconveniences for instances.
The text was updated successfully, but these errors were encountered:
With check --deploy I had a couple of warnings which I could resolve by changing some settings in RDMO and in our apache vhost config.
WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.
For SECURE_SSL_REDIRECT and SECURE_HSTS_SECONDS, I think this should be handled by nginx or apache, not the application level. (But you need the proper X-Forwarded-Proto for it to work.
I guess with _COOKIE_SECURE things would not work in development anymore. It also does not change much, it prevents that the page is usable by HTTP only, which should not happen in the firstplace. But there are cases, where people might to run RDMO in "production" without SSL, to test it or to show it to people in an intranet. I would keep those settings.
I learned something today about reverse proxy setups...
is not ideal, because it sets the
Host
header to the original host header.X-Forwarded-For
is the orginal IP andX-Forwarded-Proto
is e.g.https
.Better would be
which sets the
X-Forwarded-Host
header. For this to workUSE_X_FORWARDED_HOST = True
needs to be true in the RDMO settings.For the gunicorn setup it even works when the
proxy_set_header
are omitted, since I introduced https://github.com/rdmorganiser/rdmo/blob/main/rdmo/core/settings.py#L7, and the host when running gunicorn locally is ...localhost
.Django sets the "local" allowed hosts automatically when
DEBUG = True
(https://github.com/rdmorganiser/rdmo/blob/main/rdmo/core/settings.py#L7) so we should remove this settings again.USE_X_FORWARDED_HOST = True
is not needed when running RDMO in Apache so we should not add it to RDMO by default. I think we should add it to rdmo-app and document it properly, but there could be some inconveniences for instances.The text was updated successfully, but these errors were encountered: