Proxy servers act as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service or available resource from a different server, and the proxy server evaluates the request as a way to simplify and control its complexity.
Sessions in Tower associate an IP address upon creation. Tower policy requires that any use of the session match the original associated IP address.
To provide proxy server support, Tower handles proxied requests (such as ELB in front of Tower, HAProxy, Squid, and tinyproxy) via the REMOTE_HOST_HEADERS
list variable in Tower settings (/etc/tower/conf.d/remote_host_headers.py
). By default REMOTE_HOST_HEADERS
is set to ['REMOTE_ADDR', 'REMOTE_HOST']
.
To enable proxy server support, setup REMOTE_HOST_HEADERS
like the following:
REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST']
Tower determines the remote host’s IP address by searching through the list of headers in REMOTE_HOST_HEADERS
until the FIRST IP address is located.
Note
Header names are constructed using the following logic:
With the exception of CONTENT_LENGTH
and CONTENT_TYPE
, any HTTP headers in the request are converted to META keys by converting all characters to uppercase, replacing any hyphens with underscores, and adding an HTTP_
prefix to the name. For example, a header called X-Barkley
would be mapped to the META key HTTP_X_Barkley
.
For more information on HTTP request and response objects, refer to: https://docs.djangoproject.com/en/1.8/ref/request-response/#django.http.HttpRequest.META
If you are behind a reverse proxy, you may want to setup a header field for HTTP_X_FORWARDED_FOR
. The X-Forwarded-For
(XFF) HTTP header field identifies the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.
REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST']