CSRF_TRUSTED_ORIGINS no longer filled by EXTERNAL_HOST

[Vaelatern]

Summary: Zulip 5.0 -> 6.1. I had to adjust my settings.py to include CSRF_TRUSTED_ORIGINS and filled the array with the value already in EXTERNAL_HOST. This seems to be due to a django change in 4.0 where the CSRF_TRUSTED_ORIGINS array no longer gets populated by headers that are missing the scheme.

Thread: https://chat.zulip.org/#narrow/stream/9-issues/topic/Zulip.206.2E0.20behind.20reverse.20proxy.20-.20CSRF.20verification.20failed

Possible upstream note (changed in 4.0): https://docs.djangoproject.com/en/4.1/ref/settings/#csrf-trusted-origins

From the 5.0 server (works without change):

$ ./deployments/current/scripts/get-django-setting CSRF_TRUSTED_ORIGINS
[]
$ ./deployments/current/scripts/get-django-setting ALLOWED_HOSTS
['127.0.0.1', 'localhost', 'chat.redacted.com', '.chat.redacted.com']
$ ./deployments/current/scripts/get-django-setting EXTERNAL_HOST
chat.redacted.com

From the 6.1 server (Before change, most queries failing with

$ ./deployments/current/scripts/get-django-setting CSRF_TRUSTED_ORIGINS
[]
$ ./deployments/current/scripts/get-django-setting ALLOWED_HOSTS
['127.0.0.1', 'localhost', 'chat.redacted.com', '.chat.redacted.com']
$ ./deployments/current/scripts/get-django-setting EXTERNAL_HOST
chat.redacted.com

After the fix (server operating normally):

$ ./deployments/current/scripts/get-django-setting CSRF_TRUSTED_ORIGINS
["https://chat.redacted.com", "http://127.0.0.1", "http://localhost"]
$ ./deployments/current/scripts/get-django-setting ALLOWED_HOSTS
['127.0.0.1', 'localhost', 'chat.redacted.com', '.chat.redacted.com']
$ ./deployments/current/scripts/get-django-setting EXTERNAL_HOST
chat.redacted.com

To be clear, I set CSRF_TRUSTED_ORIGINS to that value in my settings.py, there is nothing there that is unexpected.

Possible reason it's rare for people to notice this: If the scheme matches what the server is listening on, then perhaps Django checks with ALLOWED_HOSTS. However since I'm passing https traffic through a reverse proxy to http perhaps that is where Django is getting confused. It is possible that if I set a self-signed certificate, this issue would not have bit me.

[Vaelatern]

This would be fixed by a documentation change.

nginx reverse proxies (and probably others) need to set the scheme correctly when doing forwarding:

proxy_set_header        X-Forwarded-Proto https;

[zulipbot]

Hello @zulip/server-production members, this issue was labeled with the "area: production", "area: documentation (production)" labels, so you may want to check it out!

[AbhishekCS3459]

@Vaelatern I am really too excited to contribute to this issue, please please assign it to me.

[AbhishekCS3459]

@zulipbot Please Assign it to me I can come up with a solution soon.

[Vaelatern]

I have a PR open....

[sivangbagri]

@zulipbot claim

[zulipbot]

Hello @sivangbagri!

Thanks for your interest in Zulip! You have attempted to claim an issue without the label "help wanted". You can only claim and submit pull requests for issues with the help wanted label.

If this is your first time here, we recommend reading our guide for new contributors before getting started.