[Web-SIG] REMOTE_ADDR and proxys

[Robert Collins]

On 11 September 2014 06:41, Collin Anderson <cmawebsite at gmail.com> wrote:
> Hi All,
>
> The CGI spec says:
>
> Script authors should be aware that the REMOTE_ADDR and REMOTE_HOST
> meta-variables (see sections 4.1.8 and 4.1.9) may not identify the
> ultimate source of the request.  They identify the client for the
> immediate request to the server; that client may be a proxy, gateway,
> or other intermediary acting on behalf of the actual source client.
>
> However, if the there is a revere proxy on the server side (such as
> nginx), it seems to me, the ip address of the "immediate request to
> the server" will be "127.0.0.1" and the actual address will be in an
> "X-Forwarded-For" header.
>
> It seems to me, it is the role of the server/gateway, not the
> application/framework to determine the "correct" client ip address and
> correctly account for the situation of being behind a known proxy.
>
> Also, I am aware of the security issues of improperly handling
> X-Forwarded-For, but that's an issue no matter where it's being
> handled.
>
> So, in the case of a reverse proxy, is it ok if the WSGI server sends
> back a REMOTE_ADDR that isn't 127.0.0.1, even if it's the immediate
> connection to the WSGI server is local?
>
> Basically can we interpret the "server" above to be the machine rather
> than the program?

FWIW I think in the specific situation of a  front-end proxy such as
squid/nginx/varnish etc talking to a backend server that that server
could set REMOTE_ADDR based on a mutually agreed header (such as
X-Forwarded-For) without that having larger implications for WSGI in
general. I'd also support having wsgiref support that as a basic
deployment feature since it would be useful for microservices
deploying within PAAS environments where a front-end LB of some sort
is a given.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud