[Zope] Apache, mod_rewrite, https working together?

[Ragnar Beer]

I think you're right. Looks good! It would be nice if there was a
possibility to also get the remote address into the log file instead
of the local one.

Ragnar

>
>I am going to use:
>http://localhost:8080/$1?REAL_REMOTE_ADDR=%{REMOTE_ADDR} [QSA,P]
>
>Note however, that the REAL_REMOTE_ADDR being pushed onto the query string
>is the REMOTE_ADDR coming from apache itself, and that it is being pushed
>last into the query string. In this sense, it is no worse than the
>via_header patch, since it is getting the REMOTE_ADDR data from the
>same place (the remote end of the socket).
>
>What happens if a remote user does specify a query string containing
>REAL_REMOTE_ADDR?
>
>Testing...
>
>I just tried url
>https://myhost/test/?REAL_REMOTE_ADDR=23.23.23.23
>
>This page shows REAL_REMOTE_ADDR as ['172.18.13.13', '23.23.23.23']
>
>This actually gives a test for spoofing attempts.
>If REAL_REMOTE_ADDR[1] exists, we have a crack attempt, which
>cn be dealt with appropriately.
>
>Finally, since the manipulation is happening inside apache itself,
>the user never sees the query string's key.
>
>So, if you are more comfortable using a rule like
>
>http://localhost:8080/$1?ZSXQWUP2SD=%{REMOTE_ADDR} [QSA,P]
>
>It is OK to do so.  The remote user can see your query string's key
>only when he can see <dtml-var REQUEST>, which is under your control.
>
>So...
>
>We can 1) detect query string spoofing, 2) use an arbitrary name,
>3) hide all this from the end user, and 4) guarantee that we have
>at least one REAL_REMOTE_ADDR, one that is as good as the via_header.
>
>Looks alright to me.
>
>------------------------------------------------------------------
>
>Another note:
>
>Even if you aren't using this for security, there can be other reasons
>to need the remote address.  Suppose you have a service that is mostly
>intranet based, with some extranet users.  Your server is at a martian
>address, and is not in the extranet DNS anyway.  In such a case, you want
>to adjust your URL's depending on whether a user in internal or external.
>There is no need to generate firewall traffic for internal users, so
>you want to present them with the direct address.  External users
>cannot see the direct address, and so have to be presented with a
>proxied (or port forwarded) address.  So, it is very useful to be
>able to distinguish whether an Authenticated User is coming from the
>inside or outside.
>
>That is, authentication is the process that lets me decide if I should
>present a page to the user (at all).  This just gives me another
>clue on _how_ I should present it.
>
>Jim Penny