Re: Cannot set remote address in valve (Tomcat 5.5)
Makes sense. I did not dig through the code of the full version RemoteIpValve so much, just enough to get the general idea (or maybe just enough to get into trouble). I have to look at the docs of our load balancer or maybe just add the proto header to the log files to see what values it gets. I know that with squid we are fine, and the server is generally accessible only through the load balancer or reverse proxy. If I can make a suggestion for the docs on google code, be specific that this valve should be in the engine and precede all other elements of the engine. This makes everything work smoothly. It may also be possible to put it outside the engine, not sure if that is a general safe case. I think the only real solution here is as you implemented, a valve that precedes log valves and other valves (many of which use the IP). Keeps the rest of the code clean and simple, the configuration is in one place instead of all over the place. By the way is it proxied or proxyfied request? :) E - Original Message - From: Cyrille Le Clerc clecl...@xebia.fr To: Tomcat Users List users@tomcat.apache.org Sent: Wed, 21 Oct 2009 06:31:57 -0700 (PDT) Subject: Re: Cannot set remote address in valve (Tomcat 5.5) Hello Elli, From what I understand of your architecture, I would configure RemoteIpValve with : Valve className = org.apache.catalina.connector.RemoteIpValve internalProxies = @load-balancer-ip trustedProxies = @the-trusted-proxy-that-is-not-the-load-balancer protocolHeader = x-forwarded-proto / Note : - do not forget to regexp escape' the ip adresses in internalProxies and trustedProxies attributes. - do not declare protocolHeader=x-forwarded-proto if your load balancer do not manage it - more docs at http://code.google.com/p/xebia-france/wiki/RemoteIpValve Thanks to this, - the 99% direct requests will reach Tomcat with x-forwarded-for=@clientIp - 1% proxyfied requests will reach Tomcat with x-forwarded-for=@clientIp, @the-trusted-proxy-that-is-not-the-load-balancer Does it make sense ? Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr On Wed, Oct 21, 2009 at 6:57 AM, Elli Albek e...@sustainlane.com wrote: A question: How do you know that a proxy is trusted? Is it by providing a list of trusted IPs in the configuration of the filter? Our load balancer is always adding the client IP as the first in the list, and it does not add its own IP to the list. The header has one IP +99% of the times, the other times there is an additional IP of a proxy that is not our load balancer (reverse proxy). So in that case, we can check that the request comes from a trusted IP list (known load balancers), and only then try to change the IP. If the client IP does not come from the load balancer, it is basically a pass through. For our system the first IP is what the load balancer sees, and the only way to spoof it is to access the server not through the load balancer. If you send a request with a spoofed header to the laod balancer, it will still add the IP of the spoofer in the beginning of the list. This may not be the general case for proxies, it is only for this case. E -Original Message- From: Cyrille Le Clerc [mailto:clecl...@xebia.fr] Sent: Thursday, October 08, 2009 1:04 AM To: Tomcat Users List Subject: Re: Cannot set remote address in valve (Tomcat 5.5) Hello Elli, I am afraid there may be a flaw in the algorythm looking for the first IP of the coma delimited x-forwarded-for header without ensuring that this first IP has been set by a trusted proxy and not by the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing can easily be achieved with tools like Firefox add-ons Modify Headers (1) and X-Forwarded-For Spoofer (2) . The forthcoming version of Apache Httpd will offer a secure mechanism to handle X-Forwarded-For with a module called mod_remoteip (3). It relies on the concept of trusted proxies which IP address can be 'swallowed'. The first IP of the list that is not a trusted proxy is seen as the real remote ip. mod_remoteip would not have been tricked by such x-forwarded-for header spoofing. Here are two java ports of mod_remoteip to handle X-Forwarded-For at the Tomcat level with a valve and at the WAR level with a servlet filter : RemoteIpValve (4) and XForwardedFilter (5). In addition to handle X-Forwarded-For, they also integrate X-Forwarded-Proto (ssl). These java ports integrate the same trusted proxies concept to prevent spoofing. Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr (1) https://addons.mozilla.org/en-US/firefox/addon/967 (2) https://addons.mozilla.org/en-US/firefox/addon/5948 (3) http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html (4) http://code.google.com/p/xebia-france/wiki/RemoteIpValve (5) http://code.google.com/p/xebia-france/wiki
Re: Cannot set remote address in valve (Tomcat 5.5)
Hello Elli, From what I understand of your architecture, I would configure RemoteIpValve with : Valve className = org.apache.catalina.connector.RemoteIpValve internalProxies = @load-balancer-ip trustedProxies = @the-trusted-proxy-that-is-not-the-load-balancer protocolHeader = x-forwarded-proto / Note : - do not forget to regexp escape' the ip adresses in internalProxies and trustedProxies attributes. - do not declare protocolHeader=x-forwarded-proto if your load balancer do not manage it - more docs at http://code.google.com/p/xebia-france/wiki/RemoteIpValve Thanks to this, - the 99% direct requests will reach Tomcat with x-forwarded-for=@clientIp - 1% proxyfied requests will reach Tomcat with x-forwarded-for=@clientIp, @the-trusted-proxy-that-is-not-the-load-balancer Does it make sense ? Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr On Wed, Oct 21, 2009 at 6:57 AM, Elli Albek e...@sustainlane.com wrote: A question: How do you know that a proxy is trusted? Is it by providing a list of trusted IPs in the configuration of the filter? Our load balancer is always adding the client IP as the first in the list, and it does not add its own IP to the list. The header has one IP +99% of the times, the other times there is an additional IP of a proxy that is not our load balancer (reverse proxy). So in that case, we can check that the request comes from a trusted IP list (known load balancers), and only then try to change the IP. If the client IP does not come from the load balancer, it is basically a pass through. For our system the first IP is what the load balancer sees, and the only way to spoof it is to access the server not through the load balancer. If you send a request with a spoofed header to the laod balancer, it will still add the IP of the spoofer in the beginning of the list. This may not be the general case for proxies, it is only for this case. E -Original Message- From: Cyrille Le Clerc [mailto:clecl...@xebia.fr] Sent: Thursday, October 08, 2009 1:04 AM To: Tomcat Users List Subject: Re: Cannot set remote address in valve (Tomcat 5.5) Hello Elli, I am afraid there may be a flaw in the algorythm looking for the first IP of the coma delimited x-forwarded-for header without ensuring that this first IP has been set by a trusted proxy and not by the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing can easily be achieved with tools like Firefox add-ons Modify Headers (1) and X-Forwarded-For Spoofer (2) . The forthcoming version of Apache Httpd will offer a secure mechanism to handle X-Forwarded-For with a module called mod_remoteip (3). It relies on the concept of trusted proxies which IP address can be 'swallowed'. The first IP of the list that is not a trusted proxy is seen as the real remote ip. mod_remoteip would not have been tricked by such x-forwarded-for header spoofing. Here are two java ports of mod_remoteip to handle X-Forwarded-For at the Tomcat level with a valve and at the WAR level with a servlet filter : RemoteIpValve (4) and XForwardedFilter (5). In addition to handle X-Forwarded-For, they also integrate X-Forwarded-Proto (ssl). These java ports integrate the same trusted proxies concept to prevent spoofing. Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr (1) https://addons.mozilla.org/en-US/firefox/addon/967 (2) https://addons.mozilla.org/en-US/firefox/addon/5948 (3) http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html (4) http://code.google.com/p/xebia-france/wiki/RemoteIpValve (5) http://code.google.com/p/xebia-france/wiki/XForwardedFilter On Mon, Oct 5, 2009 at 11:19 PM, Elli Albek e...@sustainlane.com wrote: Hi, We can add the header to the custom valves, but then in addition we have to change a few log file configurations, create a servlet filter and maybe something else I cant think of now. Basically doing the same thing a few times and keeping track of all the places that depend on the header. Ideally this would all be corrected once in the beginning of the request processing pipeline, so log file configuration, other valves and the war files will remain unchanged. Attached a Valve that does that. This is the minimum code necessary, so it should not have any significant performance impact. Feel free to use as is, not guaranteed to work, no expressed on implied warranties, not FDIC insured and may loose value. To configure Tomcat add to server.xml: Service name=Catalina Connector port=8080 .../ Engine defaultHost=localhost name=Catalina !-- This should precede all other configuration in the engine -- Valve className=org.apache.catalina.connector.RemoteIPValve/ Java class/jar should be placed in /server/lib or /server/classes
RE: Cannot set remote address in valve (Tomcat 5.5)
A question: How do you know that a proxy is trusted? Is it by providing a list
of trusted IPs in the configuration of the filter?
Our load balancer is always adding the client IP as the first in the list, and
it does not add its own IP to the list. The header
has one IP +99% of the times, the other times there is an additional IP of a
proxy that is not our load balancer (reverse proxy).
So in that case, we can check that the request comes from a trusted IP list
(known load balancers), and only then try to change the
IP. If the client IP does not come from the load balancer, it is basically a
pass through.
For our system the first IP is what the load balancer sees, and the only way to
spoof it is to access the server not through the
load balancer. If you send a request with a spoofed header to the laod
balancer, it will still add the IP of the spoofer in the
beginning of the list.
This may not be the general case for proxies, it is only for this case.
E
-Original Message-
From: Cyrille Le Clerc [mailto:clecl...@xebia.fr]
Sent: Thursday, October 08, 2009 1:04 AM
To: Tomcat Users List
Subject: Re: Cannot set remote address in valve (Tomcat 5.5)
Hello Elli,
I am afraid there may be a flaw in the algorythm looking for the
first IP of the coma delimited x-forwarded-for header without
ensuring that this first IP has been set by a trusted proxy and not by
the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing
can easily be achieved with tools like Firefox add-ons Modify Headers
(1) and X-Forwarded-For Spoofer (2) .
The forthcoming version of Apache Httpd will offer a secure
mechanism to handle X-Forwarded-For with a module called mod_remoteip
(3). It relies on the concept of trusted proxies which IP address can
be 'swallowed'. The first IP of the list that is not a trusted proxy
is seen as the real remote ip. mod_remoteip would not have been
tricked by such x-forwarded-for header spoofing.
Here are two java ports of mod_remoteip to handle X-Forwarded-For
at the Tomcat level with a valve and at the WAR level with a servlet
filter : RemoteIpValve (4) and XForwardedFilter (5). In addition to
handle X-Forwarded-For, they also integrate X-Forwarded-Proto (ssl).
These java ports integrate the same trusted proxies concept to prevent
spoofing.
Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr cyri...@cyrilleleclerc.com
http://blog.xebia.fr
(1) https://addons.mozilla.org/en-US/firefox/addon/967
(2) https://addons.mozilla.org/en-US/firefox/addon/5948
(3) http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html
(4) http://code.google.com/p/xebia-france/wiki/RemoteIpValve
(5) http://code.google.com/p/xebia-france/wiki/XForwardedFilter
On Mon, Oct 5, 2009 at 11:19 PM, Elli Albek e...@sustainlane.com wrote:
Hi,
We can add the header to the custom valves, but then in addition we have to
change a few log file configurations, create a servlet filter and maybe
something else I cant think of now. Basically doing the same thing a few
times and keeping track of all the places that depend on the header. Ideally
this would all be corrected once in the beginning of the request processing
pipeline, so log file configuration, other valves and the war files will
remain unchanged.
Attached a Valve that does that. This is the minimum code necessary, so it
should not have any significant performance impact.
Feel free to use as is, not guaranteed to work, no expressed on implied
warranties, not FDIC insured and may loose value.
To configure Tomcat add to server.xml:
Service name=Catalina
Connector port=8080 .../
Engine defaultHost=localhost name=Catalina
!-- This should precede all other configuration in the engine
--
Valve className=org.apache.catalina.connector.RemoteIPValve/
Java class/jar should be placed in /server/lib or /server/classes
E
package org.apache.catalina.connector;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javax.servlet.ServletException;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
/**
* A valve that extracts the remote IP of the client from an HTTP header
field
* passed by the proxy, and set it in the request as the original client IP.
* This valve should be the first valve in the engine, so log valves (and
* others) will see the real client IP without requiring the same code
again.
*
* @author Elli Albek, www.sustainlane.com
*/
public class RemoteIPValve extends ValveBase {
private static final Pattern ipExpr =
Pattern.compile(^[\\da-fA-F]+(\\.[\\da-fA-F]+)+);
private String forwardedForHeader = X-Forwarded-For;
public void invoke(Request request, Response response) throws
IOException, ServletException {
String header = request.getHeader
Re: Cannot set remote address in valve (Tomcat 5.5)
Hello,
I updated issue 47330 proposal : port of mod_remoteip in Tomcat
as RemoteIpValve to link to a Servlet Filter implementation of
mod_remoteip called XForwardedFilter. As detailed in the comment,
XForwardedFilter.java copyright may not fit the Apache Software
Foundation requirements as it is granted to The original author or
authors ... but it can be changed with pleasure.
Hope this helps,
Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr cyri...@cyrilleleclerc.com
http://blog.xebia.fr
On Sun, Sep 27, 2009 at 11:13 AM, Mark Thomas ma...@apache.org wrote:
Elli Albek wrote:
Hi,
We have Tomcat behind a load balancer. The servlet API and tomcat libraries
see the load balancer IP as the client IP.
I tried to write a simple valve which will extract the IP from HTTP header
X-Forwarded-For
and continue the valve chain using this IP as the client IP. This will be
the first valve in the chain, so everything will work as normal afterwards
including log files, IP filter valve, etc.
The problem I am facing, is when I try to set the remote IP on the request
from my valve, the code does nothing. This is the set method in the class
org.apache.catalina.connector.Request:
public void setRemoteAddr(String remoteAddr) {
// Not used
}
The variable is protected so I cannot access it directly from my code.
Is there any way to implement this Valve?
Is there anything already shipped in tomcat to extract the client IP from
the header?
I DO NOT want to write a servlet filter for various reasons, so I hope there
is a way to do it with a valve.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47330 is on the todo
list but my current plan is to implement it as a Filter rather than a valve.
What is the issue with using a Filter?
If you really want to write a filter than that bug report should be all
you need.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Hello Christopher, I am afraid there may be a flaw in the algorythm looking for the first IP of the coma delimited x-forwarded-for header without ensuring that this first IP has been set by a trusted proxy and not by the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing can easily be achieved with tools like Firefox add-ons Modify Headers (1) and X-Forwarded-For Spoofer (2) . This is a good point that you've raised, here: it's a lot easier to spoof an HTTP header than it is to spoof a source IP address in an IP packet. An idea to mitigate this risk is to ask the network team to remove some http headers at the entry of the platform (x-forwarded-for, x-forwarded-proto, x-forwarded-... ) but the coordination between application and network teams this requires can be difficult to achieve. The forthcoming version of Apache Httpd will offer a secure mechanism to handle X-Forwarded-For with a module called mod_remoteip (3). It relies on the concept of trusted proxies which IP address can be 'swallowed'. The first IP of the list that is not a trusted proxy is seen as the real remote ip. mod_remoteip would not have been tricked by such x-forwarded-for header spoofing. Uh huh? That seems counter-intuitive to trust the first untrusted IP address you find. I'll read about mod_remoteip and see what it's all about. My mistake, I forgot to mention that it was evaluating from the right to the left. Let's imagine my http request goes through : client - hardware-load-balancer - apache + mod_proxy_http - tomcat With load-balancer configured to overwrite x-forwarded-for and apache mod_proxy_http appending the incoming ip to x-forwarded-for header (out-of-the-box configuration). In tomcat, i will have : * request.remoteAddr = @apache * http header x-forwarded-for: @client, @hardware-load-balancer the RemoteIpValve (or XForwardedFilter) wil process : * evaluate x-forwarded-for values from right to left : 1. @hardware-load-balancer is swallowed as a trusted proxy 2. @client is the first un trusted ip address, trust it (because the hardware-loadbalancer handling of x-forwarded-for header can be trusted ) * overwrite request.remoteAddr and request.remoteHost with value @client In a scenario of x-forwarded-for header spoofing coming with value @fake, either : scenario a) The hardware-load-balancer would have overwrittent the header x-forwarded-for scenario b) The RemoteIpValve (or XForwardedFilter) would have received x-forwarded-for: @fake, @client, @hardware-load-balancer and still elect @client as the remoteAddr because it is the first not trusted ip. Hope this clarifies the behavior of the anti spoofing algorithm of mod_remoteip. Cyrille - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cyrille, On 10/9/2009 9:16 AM, Cyrille Le Clerc wrote: An idea to mitigate this risk is to ask the network team to remove some http headers at the entry of the platform (x-forwarded-for, x-forwarded-proto, x-forwarded-... ) This makes a lot of sense, except that there might be some legitimate proxies in the path that shouldn't be removed. Uh huh? That seems counter-intuitive to trust the first untrusted IP address you find. I'll read about mod_remoteip and see what it's all about. My mistake, I forgot to mention that it was evaluating from the right to the left. Aah, that makes more sense. Thanks for the clarification. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrPW28ACgkQ9CaO5/Lv0PA3ogCePMOOeDkuEwYbYdYAVhmKBDG5 t9YAnRVRhuqun7gd8mujA+xV/pFzNc2t =//Jq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Hello Christopher, An idea to mitigate this risk is to ask the network team to remove some http headers at the entry of the platform (x-forwarded-for, x-forwarded-proto, x-forwarded-... ) This makes a lot of sense, except that there might be some legitimate proxies in the path that shouldn't be removed. My idea was to cleanup headers just at the entrance of the data center. Indeed, intermediate proxies cannot cleanup headers ; otherwise, information can be lost. Uh huh? That seems counter-intuitive to trust the first untrusted IP address you find. I'll read about mod_remoteip and see what it's all about. My mistake, I forgot to mention that it was evaluating from the right to the left. Aah, that makes more sense. Thanks for the clarification. I hope one day, I will find time to blog about it with clear schemas ; it will be much more easy to understand than long sentences :-) Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Hello Elli,
I am afraid there may be a flaw in the algorythm looking for the
first IP of the coma delimited x-forwarded-for header without
ensuring that this first IP has been set by a trusted proxy and not by
the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing
can easily be achieved with tools like Firefox add-ons Modify Headers
(1) and X-Forwarded-For Spoofer (2) .
The forthcoming version of Apache Httpd will offer a secure
mechanism to handle X-Forwarded-For with a module called mod_remoteip
(3). It relies on the concept of trusted proxies which IP address can
be 'swallowed'. The first IP of the list that is not a trusted proxy
is seen as the real remote ip. mod_remoteip would not have been
tricked by such x-forwarded-for header spoofing.
Here are two java ports of mod_remoteip to handle X-Forwarded-For
at the Tomcat level with a valve and at the WAR level with a servlet
filter : RemoteIpValve (4) and XForwardedFilter (5). In addition to
handle X-Forwarded-For, they also integrate X-Forwarded-Proto (ssl).
These java ports integrate the same trusted proxies concept to prevent
spoofing.
Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr cyri...@cyrilleleclerc.com
http://blog.xebia.fr
(1) https://addons.mozilla.org/en-US/firefox/addon/967
(2) https://addons.mozilla.org/en-US/firefox/addon/5948
(3) http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html
(4) http://code.google.com/p/xebia-france/wiki/RemoteIpValve
(5) http://code.google.com/p/xebia-france/wiki/XForwardedFilter
On Mon, Oct 5, 2009 at 11:19 PM, Elli Albek e...@sustainlane.com wrote:
Hi,
We can add the header to the custom valves, but then in addition we have to
change a few log file configurations, create a servlet filter and maybe
something else I cant think of now. Basically doing the same thing a few
times and keeping track of all the places that depend on the header. Ideally
this would all be corrected once in the beginning of the request processing
pipeline, so log file configuration, other valves and the war files will
remain unchanged.
Attached a Valve that does that. This is the minimum code necessary, so it
should not have any significant performance impact.
Feel free to use as is, not guaranteed to work, no expressed on implied
warranties, not FDIC insured and may loose value.
To configure Tomcat add to server.xml:
Service name=Catalina
Connector port=8080 .../
Engine defaultHost=localhost name=Catalina
!-- This should precede all other configuration in the engine
--
Valve className=org.apache.catalina.connector.RemoteIPValve/
Java class/jar should be placed in /server/lib or /server/classes
E
package org.apache.catalina.connector;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javax.servlet.ServletException;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
/**
* A valve that extracts the remote IP of the client from an HTTP header
field
* passed by the proxy, and set it in the request as the original client IP.
* This valve should be the first valve in the engine, so log valves (and
* others) will see the real client IP without requiring the same code
again.
*
* @author Elli Albek, www.sustainlane.com
*/
public class RemoteIPValve extends ValveBase {
private static final Pattern ipExpr =
Pattern.compile(^[\\da-fA-F]+(\\.[\\da-fA-F]+)+);
private String forwardedForHeader = X-Forwarded-For;
public void invoke(Request request, Response response) throws
IOException, ServletException {
String header = request.getHeader(forwardedForHeader);
String forwardedIP = getFirstIP(header);
if (forwardedIP != null)
request.remoteAddr = forwardedIP;
next.invoke(request, response);
}
/**
* Return the first IP address in a string that may contain an IP list
*/
static final String getFirstIP(String header) {
if (header == null)
return null;
Matcher m = ipExpr.matcher(header);
if (m.find()) {
return m.group();
}
return null;
}
public void setForwardedForHeader(String forwardedForHeader) {
this.forwardedForHeader = forwardedForHeader;
}
public String getInfo() {
return RemoteIPValve;
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cyrille, On 10/8/2009 4:03 AM, Cyrille Le Clerc wrote: I am afraid there may be a flaw in the algorythm looking for the first IP of the coma delimited x-forwarded-for header without ensuring that this first IP has been set by a trusted proxy and not by the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing can easily be achieved with tools like Firefox add-ons Modify Headers (1) and X-Forwarded-For Spoofer (2) . This is a good point that you've raised, here: it's a lot easier to spoof an HTTP header than it is to spoof a source IP address in an IP packet. The forthcoming version of Apache Httpd will offer a secure mechanism to handle X-Forwarded-For with a module called mod_remoteip (3). It relies on the concept of trusted proxies which IP address can be 'swallowed'. The first IP of the list that is not a trusted proxy is seen as the real remote ip. mod_remoteip would not have been tricked by such x-forwarded-for header spoofing. Uh huh? That seems counter-intuitive to trust the first untrusted IP address you find. I'll read about mod_remoteip and see what it's all about. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrOdn0ACgkQ9CaO5/Lv0PBJtACggGynXG9+5aTVIntOzJ3rB4Ie ZZ4AoLTmXelgtQEC6+udWuCSyQsqQnTc =cYNl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
I know I'm late in this discussion. Besides the very good mentioning of mod_remoteip, RemoteIpValve and XForwardedFilter I guess there's a way of doing it in case you are using mod_jk. mod_jk (and mod_proxy_ajp) use the AJP protocol between the web server and the backend, e.g. Tomcat. This protocol transports the original communication information from the web server to the backend, and when remote IP etc., it doesn't get the backend data (e.g. the client of the backend is the web server, not very intersting), but instead the data forwarded by the web server. Since few versions of mod_jk we allow this data to be influenced by the admin of the web server. Most of the data can be taken from mod_jk out of so-called environment variables of Apache httpd, and those variables can be manipulated by mod_rewrite. With a little config magic you could e.g. - Let mod_rewrite check, whether the X-Forwarded-For header was set - Let mod_rewrite check, whether there's more than on IP in it, if yes extract the first one, if no take the whole header - Put the result into the magic env var and now mod_jk will forward this result as the remote IP address instead of the one retrieved from the TCP connection. For details see: http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html and http://tomcat.apache.org/connectors-doc/reference/apache.html Warning: you very likely would need to use Apache httpd 2.2, because before mod_rewrite might not have been powerful enough. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
- Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Fri, 2 Oct 2009 07:32:06 -0700 (PDT) Subject: Re: Cannot set remote address in valve (Tomcat 5.5) 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? To be more specific, i was referring to a request filter that is implemented as a valve, not as a servlet filter. One is shipped with tomcat already for filtering IPs. That valve does not work behind a load balancer or a reverse proxy. E - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
To make it clear, valves are executed around the web apps, so they are executed before the request gets to any servlet filter. Servlet filter behavior is defined by the Servlet specification. Valves are tomcat specific classes that contain some core server functionality that is not defined by the spec as an interface. E - Original Message - From: Tim Funk funk...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Fri, 2 Oct 2009 07:46:14 -0700 (PDT) Subject: Re: Cannot set remote address in valve (Tomcat 5.5) Context filters are executed before webapp filters. I believe (but not confirmed) that valves execute before the filters. -Tim Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/2/2009 5:55 AM, Mark Thomas wrote: Elli Albek wrote: A few reasons why not to do this as a servlet filter: 1. There are many web apps on the server and I don't want to include the filter in each. You don't have to. Configure it in the global web.xml. Are the filters configured in conf/web.xml considered before those in WEB-INF/web.xml... that is, will they be called before the webapp-defined ones? 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Hello Christopher, Using a Remote IP Filtering Valve/Servlet Filter can be a bit tricky with a proxy or a load balancer because, by default, you loose the actual remote ip and just get the IP of the proxy or load balancer. However, these proxies and load balancer (Apache mod_proxy, F5 Big IP, Alteon, Squid, etc) add an HTTP Header commomly named X-Forwarded-For (or X-Client-IP) to transmit the actual remote IP. Apache Httpd will integrate the mod_remoteip (http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html) module to handle X-Forwarded-For header at the Apache Httpd layer. Here are two java ports of mod_remoteip to handle X-Forwarded-For at the Tomcat level with a valve and at the WAR level with a servlet filter : RemoteIpValve (http://code.google.com/p/xebia-france/wiki/RemoteIpValve) and XForwardedFilter (http://code.google.com/p/xebia-france/wiki/XForwardedFilter). In addition to handle X-Forwarded-For, they also integrate X-Forwarded-Proto (http or https). Thanks to this, request.getRemoteAddr(), request.getRemoteHost(), request.isSecure(), request.getScheme() and request.getServerPort() will expose the values transmitted by X-Forwarded-For and X-Forwarded-Proto rather than the values of the preceding proxy / load balancer. For your need, preceding the RemoteAddrValve by the RemoteIpValve would allow you to get the actual client IP, The RemoteIpValve has been proposed to the Tomcat project as Bug 47330 - proposal : port of mod_remoteip in Tomcat as RemoteIpValve (https://issues.apache.org/bugzilla/show_bug.cgi?id=47330) . Hope this helps, Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr On Mon, Oct 5, 2009 at 12:43 PM, Elli Albek e...@sustainlane.com wrote: - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Fri, 2 Oct 2009 07:32:06 -0700 (PDT) Subject: Re: Cannot set remote address in valve (Tomcat 5.5) 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? To be more specific, i was referring to a request filter that is implemented as a valve, not as a servlet filter. One is shipped with tomcat already for filtering IPs. That valve does not work behind a load balancer or a reverse proxy. E - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cannot set remote address in valve (Tomcat 5.5)
Hi,
We can add the header to the custom valves, but then in addition we have to
change a few log file configurations, create a servlet filter and maybe
something else I cant think of now. Basically doing the same thing a few
times and keeping track of all the places that depend on the header. Ideally
this would all be corrected once in the beginning of the request processing
pipeline, so log file configuration, other valves and the war files will
remain unchanged.
Attached a Valve that does that. This is the minimum code necessary, so it
should not have any significant performance impact.
Feel free to use as is, not guaranteed to work, no expressed on implied
warranties, not FDIC insured and may loose value.
To configure Tomcat add to server.xml:
Service name=Catalina
Connector port=8080 .../
Engine defaultHost=localhost name=Catalina
!-- This should precede all other configuration in the engine
--
Valve className=org.apache.catalina.connector.RemoteIPValve/
Java class/jar should be placed in /server/lib or /server/classes
E
package org.apache.catalina.connector;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javax.servlet.ServletException;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
/**
* A valve that extracts the remote IP of the client from an HTTP header
field
* passed by the proxy, and set it in the request as the original client IP.
* This valve should be the first valve in the engine, so log valves (and
* others) will see the real client IP without requiring the same code
again.
*
* @author Elli Albek, www.sustainlane.com
*/
public class RemoteIPValve extends ValveBase {
private static final Pattern ipExpr =
Pattern.compile(^[\\da-fA-F]+(\\.[\\da-fA-F]+)+);
private String forwardedForHeader = X-Forwarded-For;
public void invoke(Request request, Response response) throws
IOException, ServletException {
String header = request.getHeader(forwardedForHeader);
String forwardedIP = getFirstIP(header);
if (forwardedIP != null)
request.remoteAddr = forwardedIP;
next.invoke(request, response);
}
/**
* Return the first IP address in a string that may contain an IP list
*/
static final String getFirstIP(String header) {
if (header == null)
return null;
Matcher m = ipExpr.matcher(header);
if (m.find()) {
return m.group();
}
return null;
}
public void setForwardedForHeader(String forwardedForHeader) {
this.forwardedForHeader = forwardedForHeader;
}
public String getInfo() {
return RemoteIPValve;
}
}
RE: Cannot set remote address in valve (Tomcat 5.5)
Yes, the remoteAddress member is protected. So you can only access it if you
put your class in the same package.
I thought of doing it like a filter (wrapping) but it does not look like a
workable solution in this case.
1. The request class is final (which basically ends the discussion :)
2. This class is not a simple placeholder for values or a wrapper. It is a
heavy object that is recycled at the end of the request processing and
contains a lot of code. I don't have any intention to get into Tomcat
internal resource management and object recycling code. It seems pretty
complicated. I don't think you can just replace a server object as you can
do with a servlet request wrapper that is basically a proxy.
E
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, October 01, 2009 8:43 AM
To: Tomcat Users List
Subject: Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elli,
On 9/27/2009 12:19 AM, Elli Albek wrote:
public void setRemoteAddr(String remoteAddr) {
// Not used
}
The variable is protected so I cannot access it directly from my code.
What variable? The remoteAddress member?
Is there any way to implement this Valve?
Wrap the request object in a subclass that you write. This will allow
you to either
a) Override the setRemoteAddress method to return whatever you want
b) Explicitly set the remoteAddress member to whatever you want
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrEzh0ACgkQ9CaO5/Lv0PAmqwCeJpvyj0k9Ze+QKLkyRNqfpvzp
nccAniLAI/gdF65qw9EF6HLsXqcSgacP
=S2JM
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cannot set remote address in valve (Tomcat 5.5)
A few reasons why not to do this as a servlet filter: 1. There are many web apps on the server and I don't want to include the filter in each. 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. 3. We have a few environments and I don't want to have different war configurations for each. We had servers with and without load balancers and I can see that change again in the near future. This should not affect the application configuration. 4. It is logically part of the server environment and not part of the web application. The web application should not change based on the network architecture. If the system admin adds/removes the load balancer then he should know about one thing he needs to change in tomcat, and not rebuild all the wars without a filter. Network configuration should not require code rebuild with/without filters (we have to do a build to create war, like most people). E -- What about just implementing this as a filter and then construct a request wrapper in the filter to read that header and override the getRemoteAddr() method. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Elli Albek wrote: A few reasons why not to do this as a servlet filter: 1. There are many web apps on the server and I don't want to include the filter in each. You don't have to. Configure it in the global web.xml. 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. The valve is a problem and that does limit your options. This should be better in Tomcat 7 where the Servlet spec includes programmatic login so you might be able to move your valve to a filter. 3. We have a few environments and I don't want to have different war configurations for each. We had servers with and without load balancers and I can see that change again in the near future. This should not affect the application configuration. Essentially the same issue as 1 - setting the filter globally should address this. 4. It is logically part of the server environment and not part of the web application. The web application should not change based on the network architecture. If the system admin adds/removes the load balancer then he should know about one thing he needs to change in tomcat, and not rebuild all the wars without a filter. Network configuration should not require code rebuild with/without filters (we have to do a build to create war, like most people). Same as 3. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Elli, On 10/2/2009 4:41 AM, Elli Albek wrote: Yes, the remoteAddress member is protected. So you can only access it if you put your class in the same package. I thought of doing it like a filter (wrapping) but it does not look like a workable solution in this case. Why not? 1. The request class is final (which basically ends the discussion :) I think you may be looking at the wrong Request class. You want org.apache.catalina.connector.Request, not org.apache.coyote.Request. The former is not final. Check the javadoc for the Valve class: http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/Valve.html and this enhancement request in bugzilla: https://issues.apache.org/bugzilla/show_bug.cgi?id=45014 Feel free to use my wrapper classes (with appropriate modifications, of course). 2. This class is not a simple placeholder for values or a wrapper. It is a heavy object that is recycled at the end of the request processing and contains a lot of code. I don't have any intention to get into Tomcat internal resource management and object recycling code. You don't need to do any of that. Wrapping a request and/or response is trivial, non-invasive, and you don't have to mess with any Tomcat internals. It seems pretty complicated. I don't think you can just replace a server object as you can do with a servlet request wrapper that is basically a proxy. Why not? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrGDkgACgkQ9CaO5/Lv0PBE5ACfa+jwGF24WYiQM//BB4aVgfvv +usAn0njiqTmYnTDF1ldfJr5APJgP9O3 =pw9b -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/2/2009 5:55 AM, Mark Thomas wrote: Elli Albek wrote: A few reasons why not to do this as a servlet filter: 1. There are many web apps on the server and I don't want to include the filter in each. You don't have to. Configure it in the global web.xml. Are the filters configured in conf/web.xml considered before those in WEB-INF/web.xml... that is, will they be called before the webapp-defined ones? 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrGDuYACgkQ9CaO5/Lv0PC+YwCdEtcAtlZYl4L3ErA3WHeUjmD/ h+4AnA2nvWKU6fEVpRF00K/FrKJ8h8dh =k4wA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Christopher Schultz wrote: Mark, On 10/2/2009 5:55 AM, Mark Thomas wrote: Elli Albek wrote: A few reasons why not to do this as a servlet filter: 1. There are many web apps on the server and I don't want to include the filter in each. You don't have to. Configure it in the global web.xml. Are the filters configured in conf/web.xml considered before those in WEB-INF/web.xml... that is, will they be called before the webapp-defined ones? I believe so, yes. 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? Yes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Context filters are executed before webapp filters. I believe (but not confirmed) that valves execute before the filters. -Tim Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/2/2009 5:55 AM, Mark Thomas wrote: Elli Albek wrote: A few reasons why not to do this as a servlet filter: 1. There are many web apps on the server and I don't want to include the filter in each. You don't have to. Configure it in the global web.xml. Are the filters configured in conf/web.xml considered before those in WEB-INF/web.xml... that is, will they be called before the webapp-defined ones? 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cannot set remote address in valve (Tomcat 5.5)
From: Tim Funk [mailto:funk...@apache.org] Subject: Re: Cannot set remote address in valve (Tomcat 5.5) Context filters are executed before webapp filters. I'll bite: what's the difference between a context filter and a webapp filter? Aren't all filters are configured in some web.xml? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Cannot set remote address in valve (Tomcat 5.5)
My bad - by context filter I meant to say the web.xml as found in $CATALINA_HOME/conf/web.xml There is nothing contexty about it -Tim Caldarale, Charles R wrote: From: Tim Funk [mailto:funk...@apache.org] Subject: Re: Cannot set remote address in valve (Tomcat 5.5) Context filters are executed before webapp filters. I'll bite: what's the difference between a context filter and a webapp filter? Aren't all filters are configured in some web.xml? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/2/2009 10:45 AM, Mark Thomas wrote: Christopher Schultz wrote: 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? Yes. Okay, then a Filter isn't going to work for Elli, since they are trying to use a custom Valve for authentication which needs the IP address to be correct. On the other hand, they could just modify their custom authentication Valve to check for X-Forwarded-For /first/, and then callback to request.getRemoteAddress. I'm not sure why this is so confusing to everyone :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrGL1oACgkQ9CaO5/Lv0PBEgQCfUUX+bHt42WVnWLez9EZ9lxzK +7EAnjSrw0R20AeU7MLC2aHIj4lJ0Ja/ =RBVy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Christopher Schultz wrote: Mark, On 10/2/2009 10:45 AM, Mark Thomas wrote: Christopher Schultz wrote: 2. There are other valves like request filters that cannot work without the correct IP, as well as custom login valve. Filters should be OK providing they are defined in the right order. Aren't all Valves always called before Filters? Yes. Okay, then a Filter isn't going to work for Elli, since they are trying to use a custom Valve for authentication which needs the IP address to be correct. I know. I said that a couple of mails ago. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elli,
On 9/27/2009 12:19 AM, Elli Albek wrote:
public void setRemoteAddr(String remoteAddr) {
// Not used
}
The variable is protected so I cannot access it directly from my code.
What variable? The remoteAddress member?
Is there any way to implement this Valve?
Wrap the request object in a subclass that you write. This will allow
you to either
a) Override the setRemoteAddress method to return whatever you want
b) Explicitly set the remoteAddress member to whatever you want
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrEzh0ACgkQ9CaO5/Lv0PAmqwCeJpvyj0k9Ze+QKLkyRNqfpvzp
nccAniLAI/gdF65qw9EF6HLsXqcSgacP
=S2JM
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Elli Albek wrote:
Hi,
We have Tomcat behind a load balancer. The servlet API and tomcat libraries
see the load balancer IP as the client IP.
I tried to write a simple valve which will extract the IP from HTTP header
X-Forwarded-For
and continue the valve chain using this IP as the client IP. This will be
the first valve in the chain, so everything will work as normal afterwards
including log files, IP filter valve, etc.
The problem I am facing, is when I try to set the remote IP on the request
from my valve, the code does nothing. This is the set method in the class
org.apache.catalina.connector.Request:
public void setRemoteAddr(String remoteAddr) {
// Not used
}
The variable is protected so I cannot access it directly from my code.
Is there any way to implement this Valve?
Is there anything already shipped in tomcat to extract the client IP from
the header?
I DO NOT want to write a servlet filter for various reasons, so I hope there
is a way to do it with a valve.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47330 is on the todo
list but my current plan is to implement it as a Filter rather than a valve.
What is the issue with using a Filter?
If you really want to write a filter than that bug report should be all
you need.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Thanks for the response. Is there any problem in fixing this method to actually set the variable (which is already in the class)? I think the set methods should actually set the values, so others can write such extensions without putting their code in the apache packages. Right now I guess the only thing I can do is to either use the valve class referenced in this bug report or put my class in an apache package, which I don't think it belongs to. I see that the class you pointed to is also in an apache package just for that reason. E - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Sun, 27 Sep 2009 02:13:49 -0700 (PDT) Subject: Re: Cannot set remote address in valve (Tomcat 5.5) https://issues.apache.org/bugzilla/show_bug.cgi?id=47330 is on the todo list but my current plan is to implement it as a Filter rather than a valve. What is the issue with using a Filter? If you really want to write a filter than that bug report should be all you need. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot set remote address in valve (Tomcat 5.5)
Elli Albek wrote:
Hi,
We have Tomcat behind a load balancer. The servlet API and tomcat libraries
see the load balancer IP as the client IP.
I tried to write a simple valve which will extract the IP from HTTP header
X-Forwarded-For
and continue the valve chain using this IP as the client IP. This will be
the first valve in the chain, so everything will work as normal afterwards
including log files, IP filter valve, etc.
The problem I am facing, is when I try to set the remote IP on the request
from my valve, the code does nothing. This is the set method in the class
org.apache.catalina.connector.Request:
public void setRemoteAddr(String remoteAddr) {
// Not used
}
The variable is protected so I cannot access it directly from my code.
Is there any way to implement this Valve?
Is there anything already shipped in tomcat to extract the client IP from
the header?
I DO NOT want to write a servlet filter for various reasons, so I hope there
is a way to do it with a valve.
Any help appreciated.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
What about just implementing this as a filter and then construct a
request wrapper in the filter to read that header and override the
getRemoteAddr() method.
--David
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Cannot set remote address in valve (Tomcat 5.5)
Hi,
We have Tomcat behind a load balancer. The servlet API and tomcat libraries
see the load balancer IP as the client IP.
I tried to write a simple valve which will extract the IP from HTTP header
X-Forwarded-For
and continue the valve chain using this IP as the client IP. This will be
the first valve in the chain, so everything will work as normal afterwards
including log files, IP filter valve, etc.
The problem I am facing, is when I try to set the remote IP on the request
from my valve, the code does nothing. This is the set method in the class
org.apache.catalina.connector.Request:
public void setRemoteAddr(String remoteAddr) {
// Not used
}
The variable is protected so I cannot access it directly from my code.
Is there any way to implement this Valve?
Is there anything already shipped in tomcat to extract the client IP from
the header?
I DO NOT want to write a servlet filter for various reasons, so I hope there
is a way to do it with a valve.
Any help appreciated.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
