Forum OpenACS Development: Re: ad_conn peeraddr

Collapse
2: Re: ad_conn peeraddr (response to 1)
Posted by Gustaf Neumann on
i would not recommend to patch ad_conn, but instead to
initialize it differently, when a certain configuration parameter is used. We introduced ReverseProxyMode and check its setting in the request-processor. We use this since a few years without troubles.

ad_conn -set peer_addr [ns_conn peeraddr]

if { [ns_config -bool ns/parameters ReverseProxyMode 0] } {
set addr [lindex [ns_set iget [ns_conn headers] x-forwarded-for] end]
if {[string length $addr] > 0} {
ad_conn -set peeraddr $addr
}
}

Collapse
3: Re: ad_conn peeraddr (response to 2)
Posted by Tom Jackson on
This is a bug in AOLserver, or a limitation. There are two pieces of information. One is the ip address which AOLserver is connected to called the peeraddr in ns_conn. The other is the client ip. AOLserver uses the peeraddr for ns_conn and logging to the access.log file. It is ignorant of the client ip, but sometimes they are the same. If you overwrite the peeraddr with the client ip, it is also a bug. You should probably, for long term stability, create a new name for the new information. Then if you compare the two, you can always tell if there was a proxy or not.

I also wonder how this interacts with SSL. Doesn't SSL have to go straight through, or how does that work?

Collapse
4: Re: ad_conn peeraddr (response to 3)
Posted by Gustaf Neumann on
We use the code above with SSL via pound (client connects to pound via SSL, pound connects to backend via plain HTTP). Pound uses different backends for different tasks. So, the only complete log file is the one provided by pound, which contains as well the correct IP addresses of the clients.

On the backend side everything using ad_conn reports the client ip address as "ad_conn peeraddr" (e.g. request monitor, creation_ip in acs_objects, etc.). Since all but developer traffic (via VLAN) is routed via the reverse proxy, recording the ip address of the proxy is certainly not useful. I would call it rather a bug, seeing always the proxy's ip address, where the code-writer had obviously the intention to report the client IP address. In the parts of openacs we are using, we found no place, where having the proxy as the peer address makes sense.

however, I do agree, that in principle one should have two fields, such as peer_addr and client_addr, and that the usages should be changed from "ad_conn peeraddr" to "adconn clientaddr". However, the change above is less invasive, and one has actually always both info at hand: one can use still "ns_conn peer_addr" for the bare-bone info.

Collapse
6: Re: ad_conn peeraddr (response to 4)
Posted by Malte Sussdorff on
Gustaf (or anyone else), how do you handle the fact that you might want to force SSL connections to Pound, yet security::secure_conn_p returns 0 always (as the reverse proxy is using http to communicate to the AOLserver). Is there a trick so I can tell security::secure_conn_p that the original request is actually secure ?
Collapse
7: Re: ad_conn peeraddr (response to 6)
Posted by Gustaf Neumann on
Pound adds multiple X-SSL-* request header fields to the request. The backend can query these and could set security::secure_conn_p (see http://www.apsis.ch/pound/).
This was not an issue for us, since we only allow SSL connections from the outside world.

guess, with nginx one can get the same behavior by using proxy_set_header.

Collapse
5: Re: ad_conn peeraddr (response to 3)
Posted by Malte Sussdorff on
That is not entirely correct. If you provide the X-Forward-For header AOLserver correctly logs this into the access.log. So it is probably only an ommission.

As for the parameter suggested by Gustaf, that is fine with me as well, could you provide a full diff so we can actually TIP this? (though I cannot see why anyone would want the IP Address of the proxy when calling ad_conn peeraddr and if they want, they can still fallback to ns_conn peeraddr).