#1 by gr0ssmann
I have a public-facing server on (let's say) 10.5.0.1, which forwards requests to 10.5.0.2, which is running oTree. I noticed that this setup does not make oTree offer https:// URLs, even with the following headers set in nginx: proxy_set_header X-Forwarded-Proto https; proxy_set_header Front-End-Https on; proxy_set_header X-Forwarded-Protocol https; proxy_set_header X-Forwarded-Ssl on; proxy_set_header X-Url-Scheme https; However, if I ssh into 10.5.0.1, with remote port forwarding set such that I can let nginx forward the request to 127.0.0.1:myport, which in turn redirects it to 10.5.0.2 over the ssh tunnel, then oTree does offer https:// URLs, without any further changes required. So I guess that oTree somehow notices that the request does not originate from 127.0.0.1 and decides to use http:// instead of https://. This seems bad, since all requests, likely including those with WebSockets, are first forced through the insecure http. Is there a way to make oTree respect a header like X-Forwarded-Protocol?