tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Using RemoteAddressValve with an Apache mod_proxy_balancer
Date Sun, 20 Dec 2009 16:04:48 GMT
Mark Thomas wrote:
> On 19/12/2009 10:45, André Warnier wrote:
>> To get back to the main issue, as long as I anway get the hang of this
>> stuff, and have checked out the SVN of Tomcat anyway,
>> where in the /valves stuff do I find where it actually checks the
>> "remote IP" against which RemoteAddressValve operates ?
> public void invoke(Request request, Response response)
>     throws IOException, ServletException {
>     process(request.getRequest().getRemoteAddr(), request, response);
> }
> It is the request.getRequest().getRemoteAddr() call.
So, to summarise the original concern :
The point was to see if it was possible to "upgrade" the 
RemoteAddressValve so that it would offer a choice, when filtering the 
"remote" IP address (for a request which came in through a proxy), 
between the original client's address, and the IP address of the proxy 
itself (the one connected directly to the Tomcat Connector socket).

The idea being, to stop some unwanted proxy server to use our services 
if we don't want to, independently of the real proxy-ed remote client.

It would seem that currently in such a case, the RemoteAddressValve 
always considers the original client's address.

The above getRemoteAddr() call refers to "request", which seems to be a 
Request as defined in connector/ :

      * Return the remote IP address making this Request.
     public String getRemoteAddr() {
         if (remoteAddr == null) {
                 (ActionCode.ACTION_REQ_HOST_ADDR_ATTRIBUTE, coyoteRequest);
             remoteAddr = coyoteRequest.remoteAddr().toString();
         return remoteAddr;

This seems to check if Request.remoteAddr has already been set, if not 
to call something to set it, and then return the address as a string.

This looks rather bad, because wherever that action above is carried 
out, it seems that it must have its own logic for determining the remote 
address.  Somewhere along the line, considering that this is a proxied 
call, it must decide to pick up the remote address from a 
"X-forwarded-for" HTTP header instead of the real IP address of the 
proxy itself.

So changing something there would probably mean quite a few cascading 
changes in multiple areas, to avoid unwanted side-effects.
One would probably have to add at least some new fields in the 
coyoteRequest, like
      * Remote address of the closest proxy.
     protected String proxyRemoteAddr = null;

      * Remote host of the closest proxy.
     protected String proxyRemoteHost = null;

      * Remote port of the closest proxy
     protected int proxyRemotePort = -1;

then the "action codes" to fill these, and so on.

I see some very suspicious comment for instance in 
coyote/ajp/ :
                  * AJP13 misses to forward the remotePort.
                  * Allow the AJP connector to add this info via
                  * a private request attribute.
                  * We will accept the forwarded data as the remote port,
                  * and remove it from the public list of request 

which does not sound very auspicious.

In other words : it seems that quite early in the request process, a 
decision is taken to *replace* the remote IP address as obtained from 
the socket, by the ultimate IP of the client for which this proxy 
request is being processed.  This casts a doubt on the ability of even a 
servlet filter to obtain the IP address of the proxy server which has 
the real connection with Tomcat.

All a bit beyond my dabbling capabilities, I'm afraid.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message