[Zope] accessing REMOTE_ADDR
Tue, 2 Oct 2001 12:42:50 -0400
On Tue, Oct 02, 2001 at 05:29:00PM +0100, Richard Barrett wrote:
> At 21:47 01/10/2001 -0500, Timothy Wilson wrote:
> >Hi everyone,
> 2. Increasingly, and probably mainly, the machine on which your client's
> browser is running will itself be hiding behind some sort of firewall with
> some sort of HTTP proxy on that firewall through which all outgoing browser
> requests pass. It may be soemthing as simple as a DSL Router which uses NAT
> to allow multiple machines to share the single DSL internet connection. The
> whole purpose of such proxies and routers is to hide user machines from the
> hackers out there in webland; to not reveal the IP numbers on the lan
> inside the firewall which, increasingly, are likely to be private IP
> numbers and thus meaningless outside the user's local network. Thus all you
> can determine is the IP number of the machine which originated the incoming
> connection to your server. You cannot detemine whether or not this is a
> real user's machine, an HTTP proxy on a firewall, the IP number of the
> user's personal firewall machine which just did NAT on the request ...
And here you have just bumped up against reason that 'who cares' is not
correct. Suppose you have a system that is behind a firewall and serves
content of use to both people inside the firewall and outside it.
Suppose further that you are reasonable and that your internal network
has only martian addresses. Then you will want to write URLs so that
your internal users address the machine directly, without passing
through the firewall or an additional proxy server. You have to
write external URLs to your firewall.
Note, you are making no security decision on the IP at all (although you
can reasonably safely make a distinction between martian/non-martian).
You are making an efficiency and possibly a latency decision.
> 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.