I have done a search on the forum and not been able to come up with anything that answers the problem so am posting a new threat...

(obviously, the use of 'domainname.com' below is instead of the real domain name).

The setup...

I have two web servers (seperate machines), one serves the main website, is where the main www.domainname.com points to. The other server is actually a file server for the internal network, and thus holds the idividual user's home pages under /home/username/public_html and serves them through apache on www2.domainname.com.

I have set up apache on www.domainname.com with a rewrite rule and proxypassreverse to proxy all requests for www.domainname.com/~username to www2.domainname.com/~username so it looks as though it is still being served from www.domainnam.com.

The problem...

Some of the users are using .htaccess files within their personal home space to restrict access to specific IP addresses or network adresses. With this configuration setup these 'Allow From' directives no longer work as the www2. domainname.com server thinks all requests are comming from www.domainname.com.

The question...

How can I configure the two servers so that I can still use the 'Allow From' directives in user's .htaccess files but still be able to proxy all the requests through the www.domainname.com server.

I hope this makes sence. I hope that there is a rather simple solution to this that I am missing.

Any help is very much appreciated.

I assume the problem is your users are putting a full hostname into the .htaccess files. What about using a partial domain name? They can just put "domainname.com" instead of putting the www or www2 at the beginning. This depends on your dns being setup correctly. They can also use IP addresses instead of hostnames.

http://httpd.apache.org/docs-2.0/mod/mod_access.html

No, not really. The problem is that the users are wanting to restrict access to certain subdirectories to the local network (for example) so are putting in the partial IP address which will map to only computers on the network they want to restrict too, the problem is the when the www2. server gets the request, which is proxied through www, the only IP address it knows about is that of the www server and thus ALL requests are allowed, regardless of where they originate.

For example, let's assume...

local network = 192.168.0.0/255.255.255.0

Machines IP's are...

www server IP is 192.168.0.1
www2 server IP is 192.168.0.2


A user's .htaccess file states...

Deny from all
Allow from 192.168.0.

... thus limiting to local network only.

the www.domainname.com url points too 192.168.0.1.

someone with an IP of 192.168.5.44 makes a request for ...

http://www.domainname.com/~username

... The .htaccess file should mean that this request is denied. However...

192.168.0.1 recieves the request, follows the rewrite rule which proxies this request to www2.domainname.com/~username.

192.168.0.2 recieves a request for...
http://www2.domainname.com/~username

... and processes it, see's the .htaccess file in the user's homespace, looks at it and compairs the IP address of the machine making the request with that in the 'allow from' line. The ONLY IP address that the machine knows about is 192.168.0.1 (the machine that is proxying the request), since 192.168.0.1 matches the 'allow from' line it continues to process the request, forwards the requested page to the client (192.168.0.1).

192.168.0.1 recieves the page from 192.168.0.2, does a little rewriting of the HTML urls and then forwards that page onto the client who requested it in the first place (192.168.5.44).

192.168.5.44 recieves the page and displays it on in the broswer even though the site has a .htaccess file that should restrict it to only IP address 192.168.0.

I have solved the problem, not in exactly the way I had hoped, but I think it is going to be the best solution available...

www.domain.name server has...

RewriteRule ^/~(.+) /~$1 [E=IP:%{REMOTE_ADDR}]
RequestHeader set REMOTE_IP %{IP}e
RewriteRule ^/~([^/]+)(.*)$ http://www2.domain.name/~$1$2 [NC,P,L]

The first line does not change the URI but does add an environment variable called IP. I think this is a little strange a way to do it, but I could not get the environment variable to be set any other way. (setenv and setenvif would not let me set the value using %{REMOTE_ADDR}).

The second line sets a request header to the value of the IP environment variable. Again, a bit of a strange way of doing this but the RequestHeader directive would not let me use %{REMOTE_ADDR} value, it just ended up setting the REMOTE_IP header to null. This was the only way I could get it to set the header to the value of the client IP.

www2.domain.name server has...

RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.1$
RewriteRule ^/(.*) http://www.domain.name/$1 [NC,R]

SetEnvIf REMOTE_IP "^192\.168\.0\.[0-9]+.*$" LOCALNET=1

The two Rewrite lines simple causes any direct request on www2. to be redirected to www. Thus setting the Request Header (by www) and allowing the .htaccess restrictions to hold.

The SetEnvIf line simply sets an environment variable 'LOCALNET' IF the Header REMOTE_IP matches the IP address defined in the regex.

The .htaccess file now need to be...

deny from all
allow from env=LOCALNET


Any other subdivisions of networks, IP addresses etc that need to have access controls applied to can be set with further SetEnvIf commands. eg

SetEnvIf REMOTE_IP "^192\.168\.5\.[0-9]+.*$" OTHERNET=1

and the htaccess file needs

deny from all
allow from env=OTHERNET env=LOCALNET

in order to allow the clients from the two different networks. and so on.

Any extra SetEnvIf directives that are needed can be applied to the individual user's .htaccess file.


This allows the user to cotrol access to the resource based upon the IP of the originating client.

It has taken me about 2 days to work this one out, so I'm pretty pleased with myself at the moment. As I say, it is not perfect, as it is not seamless (it requires the .htaccess files to be changed), but it is as close as it is going to be I think.

Any comments on the above, please post... I do not doubt that there may well be better/more efficient ways of doing this. Also, if anyone can see a floor in it (security or otherwise) then please advise. All help/comments appreciated.