Xarthisius
commented
5 years ago Turns out that traefik passes X-Forwarded-Proto by default and no change is required to our deployment.
Closed hategan closed 5 years ago
Xarthisius
commented
5 years ago Turns out that traefik passes X-Forwarded-Proto by default and no change is required to our deployment.
This is meant to address #18. It looks like none of the trickery I tried can convince the stack we have to set the wsgi.url_scheme to what is externally visible if behind a proxy. This commit checks if the X-Forwarded-Proto header is set and, if so, sets wsgi.url_scheme to the value of X-Forwarded-Proto.
My apache does not automatically add X-Forwarded-Proto when used as a proxy, so, for this solution to work, some additional incantation in the proxy configuration may be required. I my case, this is simply 'RequestHeader set X-Forwarded-Proto "https"' for the proxy virtual site.
This may or may not have security implications. I can imagine that, if the DAV server uses wsgi.url_scheme to, for example, only allow basic authentication when 'https' is used, a malicious client could set the X-Forwarded-Proto to 'https' even when issuing a request through http, thus convincing our stack to allow basic authentication with http. This will, of course, not occur if we disable http access to the DAV stuff. Nor is this example a particular problem: if the user really wants to send their credentials unencrypted, they can do so regardless of what we enforce. I.e., they could simply put the credentials on a web page. But, anyway, there may be other scenarios and I did not consider, so we should keep that in mind.