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