django behind apache ssl proxy

[laureline.guerin@…]

I've seen some code in http/__init__.py:get_host function to handle X-FORWARDED-HOST that could be added by an apache proxy.

Unfortunately, there is no way to determine if proxy is acceded in https or http, so an issue occures when django wants to build an url for some Redirect : the url is built using the X-FORWARDED-HOST, but always assume that the proxy is non-SSL.

I think there could be some solutions to solve this issue :

• Remove test for X-FORWARDED-HOST in get_host, apache mod_proxy is designed to rewrite Location headers (used in redirect)
• If some people want to have X-FORWARDED-HOST handled in get_host, then add a setting to enable or disable it
• add a setting like 'HTTPS_PROXY=on' that would work like HTTPS=ON

[Simon Greenhill <dev@…>]

Can you raise this on the django-developers mailing list?

[Cédric RICARD]

A better solution, I think, should be to use another header (X-FORWARDER-PROTO for example) containing the scheme used by the proxy (http or https). And check into HttpRequest.is_secure() function is this header exists. If not, then use the current way.

[gisle]

I had the same issue here and worked around it by adding one more ProxyPassReverse line to my Apache configuration. Something like this:

<VirutalHost *:443>
   ServerName foo.example.com
   ProxyPass / http://localhost:8082/
   ProxyPassReverse / http://localhost:8082/
   ProxyPassReverse / http://foo.example.com/
   Include ssl-sert
</VirtualHost>

[Aymeric Augustin]

This is a duplicate of #6880. The issue in both tickets is that Django tries to perform some magic by using the non-standard (and insecure) X-Forwarded-For header, and that breaks redirects.

The latest patch for #6880 implements the first option offered by the OP: remove test for X-FORWARDED-HOST in get_host.