Closed eloraburns closed 11 years ago
Crazy question but you guys don't have a protocol hardcoded into the site record do you? (In django_site table)
Hey Taavi! I think this is the expected behavior..
Scratch that.. I should read more carefully before I type..
django/http/__init__.py
line 271: settings.SECURE_PROXY_SSL_HEADER
Thinking that NGINX is probably setting something useful for us to read; we just have to tell Django what to trust.
Hey, I don't think this is the i18n stuff causing the problem -- it's doing it on any redirect. (Go to sign up, for example, and on the redirect to next, you'll go back to HTTP)
Yeah, I think we new to set the proxy ssl setting appropriately.
taa /eof/
On 2013-05-10, at 17:25, Michael DiBernardo notifications@github.com wrote:
Hey, I don't think this is the i18n stuff causing the problem -- it's doing it on any redirect. (Go to sign up, for example, and on the redirect to next, you'll go back to HTTP)
— Reply to this email directly or view it on GitHub.
Peeking at our nginx configuration I tried adding SECURE_PROXY_SSL_HEADER = ('X-Forwarded-Protocol', 'https')
to local_settings.py
, but no dice.
Poking at this now…
Oh, right… I have run into this one before. The problem is that you're supposed to know that when the name says "HEADER", it actually means "ENVIRONMENT VARIABLE": https://django-secure.readthedocs.org/en/latest/settings.html#secure-proxy-ssl-header
I've updated production… But I don't know what the procedure for properly saving and committing things is, so I've just left the files there. All is working now, though.
:+1:
What changes were those? I don't see any orphan changes in prod…
On May 10, 2013, at 22:08, David Wolever wrote:
I've updated production… But I don't know what the procedure for properly saving and committing things is, so I've just left the files there. All is working now, though.
— Reply to this email directly or view it on GitHub.
taa /eof/
I think the reason I didn't think it was working before is that the Makefile was referring to a newly-defunct supervisord
task ("2013-staging"). On actually restarting gunicorn, things started to work. At least, that's my guess as to what happened.
I think we fixed this, eventually.
Probably an issue with the django i18n redirect