[Zope] accessing REMOTE_ADDR
Thu, 04 Oct 2001 18:45:37 +0100
At 09:03 04/10/2001 -0600, Bill Anderson wrote:
>On Tue, 2001-10-02 at 10:29, Richard Barrett wrote:
> > At 21:47 01/10/2001 -0500, Timothy Wilson wrote:
> > >Hi everyone,
> > >
> > >I've been messing around with my Apache config and the ProxyVia directive
> > >and searching the mailing list archive. I have yet to find the definitive
> > >answer to this question:
> > >
> > >Is it possible to retrieve the actual IP address of the site visitor when
> > >using Zope with Apache ProxyPass or Rewrite rules (without patching
> > In the case of mod_proxy and without patching the answer is no.
>Sorry, that is wrong.
>I am using apache 1.3.19, ProxyPass, and have the ProxyVia directive
>turned to full, and it works just fine.
>goes in the VirtualHost section in your httpd.conf file.
If you are using vanilla Apache I think you will find that in a proxied
request Zope will see the REMOTE_ADDR environment variable containing the
IP number of the Apache server and that there is also a VIA header inserted
containing the IP info of the Apache server and its version information.
The former is because that is where Zope saw the incoming connection come
from. The latter is what Apache is supposed to put in a VIA header if
ProxyVia is 'On' or 'Full'. Nothing in what is passed to Zope identifies
the IP number of the machine originating the request coming in to Apache.
Well that is what Apache 1.3.14 under Suse Linux 7.2 does for me. This is
with straight Apache proxying for a separate Zope server. I've no idea what
you get with a fastcgi or pcgi hookup between Apache and Zope.
>Now, I am not using ModRewrite, so there *may* be some issues with that.
If instead of mod_proxy and ProxyPass I use mod_rewrite with a RewriteRule
having a P (proxy) flag I get the same results. No surprise there.
> > My advice: give it up; like who cares what the IP number of the user's
> > machine is. If you are after security you've got to rely on the low grade
> > capabilities of Basic Authentication and its cookie cousins, or get some
> > serious protection by wrapping Basic Auth in SSL.
>Again, not completely true. if you use IP addresses for security
>purposes, your primary concern is spoofed IPs, If your OS allows it
>(such as Linux), you can block nearly all spoofed IP attempts.
The point I was making is that in the general internet case you have no way
of reliably determining the IP number of the machine running the client
browser which originated an HTTP Request which, finally, your server is
responding it. The proliferation of NAT and Proxies between the ultimate
client and the ultimate server prevents this information being available.
Thus you cannot base a security strategy on the IP number of the machine
the site visitor was running his browser on.
Consider what use the server can make of the IP number of a client with a
private IP number that can only reach the server through a proxy on the
border of the client's home domain; there are potentially a gazillion
machines with the IP number 172.16.5.70 and all of them have different
hostnames within their local domain. Even if you had the IP number the
information content is zero.
Even when you are servicing the incoming request in an Apache or Zope
server directly connected to the internet you can only know the IP number
of the machine at the other end of the incoming connection. In many, maybe
most cases of connections over the internet this is not the IP number of
the machine running the client browser which made the original request.
HTTP 1.1 (RFC2616) quite specifically provides no mechanism for carrying
the IP number of the initiating client forward through intermediate HTTP
proxies; there is no request header defined to carry the information;
intervening proxies, even those that are HTTP aware, have no defined place
to put the information. And even if there were somewhere to put it you
could not have any confidence in what it told you. Trivial code on any
intermediate machine can manipulate HTTP headers undetectably unless your
are using SSL.
There are patches to Apache which will, when Apache is proxying, put the IP
number from which it saw the incoming request come into a VIA header. This
is an abuse of this header which is defined to accumulate data about
intermediate proxies handling a request for purely informational purposes.
Squid can likewise insert a non-standard header X-Forwarded-For header; I
believe there is also a patch to get Apache to insert a X-Forwarded-For
header instead of a dodgy VIA.
If you use these AND control the proxy machine you can get a fairly
reliable read of the IP number of the machine that made the request to the
proxy server BUT, in the general internet case, that is not going to be the
same thing as the IP number of the machine on which the user's browser was
running. However, in some case it may be useful.
Say you want your server to behave differently for clients inside your
local network/home domain and those machines may come come direct to Zope
or via you Apache server as proxy. Then doing reverse DNS lookups of the
REMOTE_ADDR, falling back to a reverse DNS lookup of the X-Forwarded-For
header if the REMOTE_ADDR is that of your Apache proxy server, can give a
reasonably reliable confirmation that the request came from a machine in
your local network.