I am no expert in apache rewrite rules so I cant really help with those questions. I might add that the rules I send you are not run in a directory and are the only rules I use on the virtual host (appart from logging and ServerName). I don't set a DocumentRoot I just pass every single request through to Zope and do all the rest with SiteAccess Rules etc. Tom => -----Original Message----- => From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Jim => Penny => Sent: Wednesday, 13 June 2001 7:04 AM => To: tomc@evetcia.com; zope@zope.org => Subject: Re: [Zope] Apache, mod_rewrite, https working together? => => => On Tue, Jun 12, 2001 at 10:50:13AM +1000, tomc@evetcia.com wrote: => > I dont do exactly what you are looking for but I do do this: => > => > RewriteEngine on => > RewriteRule ^/(.*) => > http://localhost:8080/zopefolder/$1?REAL_HOST=%{HTTP_HOST} [QSA,P] => > ProxyPass /misc_ http://localhost:8080/misc_ => > ProxyPass /p_ http://localhost:8080/p_ => > => Thanks, I ended up with: => DocumentRoot /var/www => RewriteEngine On => RewriteLog "/var/log/apache-ssl/rewrite_log" => RewriteLogLevel 0 => ProxyRequests on => <Directory /var/www/dynamic> => RewriteEngine On => RewriteRule ^/var/www/dynamic/(.*) => http://localhost:8080/$1?REMOTE_ADDR=%{RE => MOTE_ADDR} [QSA,P] => </Directory> => => => There is a bit of magic involved in the Rule. First, http://same_host/ => is automatically dropped, this caused some grief (but is ROTFM grief, => i.e., my fault). Then Rule => RewriteRule ^(.*) => http://localhost:8080/$1?REMOTE_ADDR=%{REMOTE_ADDR} [QSA,P] => worked on my test server, but had to be modified to the above on my => production server. Haven't figured out why yet, but may never bother. => => Thanks. => => Jim => => _______________________________________________ => Zope maillist - Zope@zope.org => http://lists.zope.org/mailman/listinfo/zope => ** No cross posts or HTML encoding! ** => (Related lists - => http://lists.zope.org/mailman/listinfo/zope-announce => http://lists.zope.org/mailman/listinfo/zope-dev ) =>

On Thu, Jun 14, 2001 at 03:34:35PM +0200, Ragnar Beer wrote:

<snip>

...

DocumentRoot /var/www RewriteEngine On RewriteLog "/var/log/apache-ssl/rewrite_log" RewriteLogLevel 0 ProxyRequests on <Directory /var/www/dynamic> RewriteEngine On RewriteRule ^/var/www/dynamic/(.*) http://localhost:8080/$1?REMOTE_ADDR=%{RE MOTE_ADDR} [QSA,P] </Directory>

<snip>

Does it help much to specify REMOTE_ADDR in the query string? Fortunately this doesn't override the internal REMOTE_ADDR so that the correct IP gets logged. Otherwise what would stop people from providing a false IP? I guess the via-header patch that is mentioned in one of the howtos would be a better solution. But I haven't tried it.

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