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.
Right.
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/Request.java :
/**
* Return the remote IP address making this Request.
*/
public String getRemoteAddr() {
if (remoteAddr == null) {
coyoteRequest.action
(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/AjpAprProcessor.java :
/*
* 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
attributes.
*/
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
