Clean settings and update documentation about proxy headers.

[jochenklar]

I learned something today about reverse proxy setups...

    # our docs at https://rdmo.readthedocs.io/en/latest/deployment/gunicorn.html
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://unix:/run/gunicorn/rdmo/rdmo.sock;
    }

is not ideal, because it sets the Host header to the original host header. X-Forwarded-For is the orginal IP and X-Forwarded-Proto is e.g. https.

Better would be

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_pass http://unix:/run/gunicorn/rdmo/rdmo.sock;
    }

which sets the X-Forwarded-Host header. For this to work USE_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.

[MyPyDavid]

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.

In order to enable SECURE_SSL_REDIRECT and SECURE_HSTS_SECONDS , I have also added this X-Forwarded-Proto with the line RequestHeader set X-Forwarded-Proto "https" to our apache vhost. see eg. https://djangodeployment.readthedocs.io/en/latest/04-web-server.html#configuring-apache-for-django.

The cookie settings, SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE, could be simply enabled.
Can these not be enabled by default in the RDMO settings?

[jochenklar]

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.

[jochenklar]

@MyPyDavid we can close here, right?