from:"Cyrille Le Clerc"

Re: Proposal to contribute a SyslogAccessLogValve to the Tomcat project

2013-12-16 Thread Cyrille Le Clerc

Dear all,

I submitted Bug 55893 - Split AccessLogValve and extract the
formatting logic in an AbstractAccessLogValve.

If this split is accepted, I will then propose a SyslogAccessLogValve.

https://issues.apache.org/bugzilla/show_bug.cgi?id=55893

Cyrille

On Thu, Dec 12, 2013 at 5:41 PM, Cyrille Le Clerc
clecl...@cloudbees.com wrote:
 Hi Christopher,

 Changing the existing AccessLogValve to use a logger would have an impact on
 performances with the creation of intermediate String objects and keeping
 backward compatibility on the access logs files management (naming,
 rotation, ...) with a new LogFactory.getLogger() approach would require
 substantial efforts.

 Cyrille


 On Thu, Dec 12, 2013 at 2:56 PM, Christopher Schultz
 ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Cyrille,

 On 12/12/13, 3:56 AM, Cyrille Le Clerc wrote:
  Hello Christopher,
 
  Delegating to log4j/logback/java.util.logging could be an option
  but it would still greatly benefit of a refactoring to split the
  existing AccessLogValve into an AbstractAccessLogValve with the
  formatting logic and an AccessLogValve that would keep the logic to
  write in the file.
 
  With this split, the MyLoggingFrameworkAccessLogValve would
  extend the AbstractAccessLogValve.

 I'm not sure that's even necessary (since the current class could be
 merely changed-over to use a logger directly), although the
 AccessLogValve was designed to be fast which I believe it why it
 does not use a regular logger but rather its own write-to-disk logger.

  Regarding the existing Syslog implementations in Log4j and Logback,
  they don't yet allow user to customise the syslog header fields but
  I plan to propose to contribute these enhancements.

 Great!

  Finally, regarding the idea of injecting a logging framework jar in
  Tomcat classloader, I feel it makes things pretty difficult to
  understand with the risk of collision of the jars.

 I'm not sure that's much of a problem. First, Tomcat uses
 commons-logging and (modified) java.logging out of the box so they
 don't need to be added... just the logger that knows how to contact
 connect to syslog. Tomcat also supports using log4j which has a syslog
 appender already in it.

  As a conclusion, I would be very happy to contribute to the Tomcat
  project either the full SyslogAccessLogValve or just the split of
  the existing AccessLogValve into an AbstractAccessLogValve with the
  formatting logic and a AccessLogValve with the logic to write in
  files.

 I'll let others comment, of course.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSqcChAAoJEBzwKT+lPKRYK/kQAJ3EXU+AzaPFOFptiR4ORDad
 ouNxYec6VMQcsTbOUdQVvjPWFdXsXP370qLINR5rfXNabkrZH+xIgDiPqbwM1Uwd
 IritRUNeXdh6hSOPdXK1MDJx8lYfbopjYNC9DfP46lsOQZlU491RLN/eNW+UGkWA
 BsEu9Hk2LPwsIzdgpz7RCbuzgJmURitcpyAGtyHxkw6e/20lhvZo/SjkCGcGK3tS
 qqqWYPzoJBoWrkJYnaVi1eREcNW5mdx8kssFkdeNHSHLYyDzsb6LyrNWSDWqUYFC
 Hn0ej/NNFyJjW/I2X4MIvU30ZuhYw80Oa/ybYyP2Jss+l7gnLltS1ijeXmCoN7pn
 2JfPqHtpxNp4czQB9WfmgdUvHoYn2uMKt0lQJ13EHU/L6ATHW6zhdzGOJ1LSMfrz
 hPPS4VCxq8miE9gt+j+Q4MgguJxSTHcjlLuObWZifCqh8plWSKlyE8o50nzxn0NQ
 KtwUpsQUUlwha1PNJKWhX/XTBPYbRu0OG+aA+xrFPdJU//68ApXTICcPife05Bc0
 Et/VGgLtJt/q4KnQuIVK7uPD9dOOndMkKAhDSGCZ56TxdxWO0juR1j1lgCi+kC2C
 n0EfsuCe+JUvd5MWmBalcFno09w1tpbTSfxpspmIzwJ8Cx181P5ffDOG9lGlV2nN
 N8H6Bd+kajS9EH3BchTs
 =VgKF
 -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: Proposal to contribute a SyslogAccessLogValve to the Tomcat project

2013-12-12 Thread Cyrille Le Clerc

Hello Christopher,

Delegating to log4j/logback/java.util.logging could be an option but it
would still greatly benefit of a refactoring to split the existing
AccessLogValve into an AbstractAccessLogValve with the formatting logic and
an AccessLogValve that would keep the logic to write in the file.

With this split, the MyLoggingFrameworkAccessLogValve would extend the
AbstractAccessLogValve.

Regarding the existing Syslog implementations in Log4j and Logback, they
don't yet allow user to customise the syslog header fields but I plan to
propose to contribute these enhancements.

Finally, regarding the idea of injecting a logging framework jar in Tomcat
classloader, I feel it makes things pretty difficult to understand with the
risk of collision of the jars.

As a conclusion, I would be very happy to contribute to the Tomcat project
either the full SyslogAccessLogValve or just the split of the existing
AccessLogValve into an AbstractAccessLogValve with the formatting logic and
a AccessLogValve with the logic to write in files.

Cyrille




On Thu, Dec 12, 2013 at 3:58 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Cyrille,

 On 12/11/13, 1:49 PM, Cyrille Le Clerc wrote:
  Dear Tomcat community,
 
  We at CloudBees implemented a SyslogAccessLogValve that outputs
  the access logs to a syslog server.
 
  The support of Syslog is more detailed that what we can usually
  find in java logging libraries as it allows to * configure all the
  syslog header fields: appName, source hostname, severity and
  facility * format syslog message according the RFC 3164 and to RFC
  5424

 Honestly, I think it would make more sense for the AccessLogValve to
 be tied instead of directly to a file or syslog, to be tied instead to
 a logging API. There already exist (relatively) standard syslog sinks
 for log4j, java.util.logging, etc. Why create another one?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSqSZYAAoJEBzwKT+lPKRYQJ8P/jgRDOCvSLgjZsAkVT32fSOf
 jAGlvkKssADw3h2vEQG2rerY7jG8YVBVe6sO1CCEBBfl/rjqxSireuWTqRI0Sc12
 KPl/pYgiJQhvA1OqDvj2kZfoL4s59MVJSlN1A3ZTEs7wp1udWXN/k5tsumIKL2dE
 9/D+xDBBwbktVT8OXee6SmjGmCA3UeArVabEH67k6rPyA1koL7ScwVgTH+zbAj+b
 yf/NusknEGv1Qm37jipVV16vpV9ZR0WEHrCghtfUYtKPsPVAphZzh+DjAZ3hGW+j
 Do5m1DC/u/QOacJGMOcyrKOiMgfLV81C8x/y6M+5me0HSpYZIPKiOROgILqXyK+i
 UjKBkABWkeKL9T/0IsHAqQdfD0w37xgTb6Fa6lgq39CRQc+rdn+DuUrrg8H0pDqs
 T5bV8DXIXeyIYP0+5xpKuZJGmGdWYTiwzu15GexUBTFocfWj5A9BGN+dIm9q++hZ
 Rf1rwLaMXkXzKPXVmml+rNAELsup4S1wgQKeptCueNsloBvftZqg06QpaIPJz5WF
 1aJhc4cn9or4oQMUs2Qcc7GnU6RV1pSycI8IyDpgqV/GBX0UPJibD1D99vet9JhF
 PfOtGYrzffGC3bv9Ebo6qOHb2SH0zqCE/C4e1ImsrdLTvb3zqAKwwtsjn5y3f2Kl
 CL48rzdXsU4lgV1IAijP
 =K/kz
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Cyrille Le Clerc
email  gtalk : clecl...@cloudbees.com / mob: +33-6.61.33.69.86 / skype:
cyrille.leclerc
CloudBees, Inc
www.cloudbees.com

Re: Proposal to contribute a SyslogAccessLogValve to the Tomcat project

2013-12-12 Thread Cyrille Le Clerc

Thanks for your support Brian :-)

Regarding the performances, I'm sure that a native
SyslogAccessLogValve will have much better performances than relying
on a logging framework:
* there will be less layers to go through
* we can eliminate any String or byte[] creation which to lower the
pressure on the garbage collector
* we can leverage the org.apache.catalina.Valve#backgroundProcess()
to efficiently refresh network resources and DNS resolutions

I would be happy to contribute such native syslog implementation in
Tomcat core, in Tomcat extras or as a separated open source library.
The only help I need is the split of the AccessLogValve to reuse the
formatting logic.

Cyrille


On Thu, Dec 12, 2013 at 11:42 AM, Brian Burch br...@pingtoo.com wrote:

 On 12/12/13 08:56, Cyrille Le Clerc wrote:

 Hello Christopher,

 Delegating to log4j/logback/java.util.logging could be an option but it
 would still greatly benefit of a refactoring to split the existing
 AccessLogValve into an AbstractAccessLogValve with the formatting logic and
 an AccessLogValve that would keep the logic to write in the file.


 I raised the issue of the AccessLogValve(s) not using the tomcat logging 
 framework earlier this year. (ref: Puzzled by Access Valve Logging on the 
 dev list.) Konstantin Kolinko pointed out that I should have held the 
 discussion on the users list instead, and also that there were performance 
 reasons for leaving the existing logic alone...


 With this split, the MyLoggingFrameworkAccessLogValve would extend the
 AbstractAccessLogValve.


 I was not convinced by Konstantin, but did not have the time to undertake any 
 research. I /still/ have an item on my todo list to develop an 
 AccessLogValve that uses the implementation-defined tomcat logging framework 
 (which in my case is bound to log4j). Performance is not an issue for me, but 
 consistency of logging is more important.

 My first task was to split the logger class in exactly the way Cyrille 
 proposes. My initial impression several months ago was that the file handling 
 could be refactored into a separate class, which extended an abstract class 
 that performed the formatting (thus preserving a common set of formatting 
 definitions, and also preserving high performance for those installations 
 that require it).

 I am travelling at the moment, so haven't had time to review Cyrille's code. 
 However, I thought it would be helpful to register my thoughts as quickly as 
 possible.

 I hope his proposal is evaluated in a positive light. It isn't high priority, 
 but I think it represents a valuable step forward with code that hasn't 
 changed much over several releases.

 Regards,

 Brian


 Regarding the existing Syslog implementations in Log4j and Logback, they
 don't yet allow user to customise the syslog header fields but I plan to
 propose to contribute these enhancements.

 Finally, regarding the idea of injecting a logging framework jar in Tomcat
 classloader, I feel it makes things pretty difficult to understand with the
 risk of collision of the jars.

 As a conclusion, I would be very happy to contribute to the Tomcat project
 either the full SyslogAccessLogValve or just the split of the existing
 AccessLogValve into an AbstractAccessLogValve with the formatting logic and
 a AccessLogValve with the logic to write in files.

 Cyrille




 On Thu, Dec 12, 2013 at 3:58 AM, Christopher Schultz 
 ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Cyrille,

 On 12/11/13, 1:49 PM, Cyrille Le Clerc wrote:

 Dear Tomcat community,

 We at CloudBees implemented a SyslogAccessLogValve that outputs
 the access logs to a syslog server.

 The support of Syslog is more detailed that what we can usually
 find in java logging libraries as it allows to * configure all the
 syslog header fields: appName, source hostname, severity and
 facility * format syslog message according the RFC 3164 and to RFC
 5424


 Honestly, I think it would make more sense for the AccessLogValve to
 be tied instead of directly to a file or syslog, to be tied instead to
 a logging API. There already exist (relatively) standard syslog sinks
 for log4j, java.util.logging, etc. Why create another one?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSqSZYAAoJEBzwKT+lPKRYQJ8P/jgRDOCvSLgjZsAkVT32fSOf
 jAGlvkKssADw3h2vEQG2rerY7jG8YVBVe6sO1CCEBBfl/rjqxSireuWTqRI0Sc12
 KPl/pYgiJQhvA1OqDvj2kZfoL4s59MVJSlN1A3ZTEs7wp1udWXN/k5tsumIKL2dE
 9/D+xDBBwbktVT8OXee6SmjGmCA3UeArVabEH67k6rPyA1koL7ScwVgTH+zbAj+b
 yf/NusknEGv1Qm37jipVV16vpV9ZR0WEHrCghtfUYtKPsPVAphZzh+DjAZ3hGW+j
 Do5m1DC/u/QOacJGMOcyrKOiMgfLV81C8x/y6M+5me0HSpYZIPKiOROgILqXyK+i
 UjKBkABWkeKL9T/0IsHAqQdfD0w37xgTb6Fa6lgq39CRQc+rdn+DuUrrg8H0pDqs
 T5bV8DXIXeyIYP0+5xpKuZJGmGdWYTiwzu15GexUBTFocfWj5A9BGN+dIm9q++hZ
 Rf1rwLaMXkXzKPXVmml

Re: Proposal to contribute a SyslogAccessLogValve to the Tomcat project

2013-12-12 Thread Cyrille Le Clerc

Hi Christopher,

Changing the existing AccessLogValve to use a logger would have an impact
on performances with the creation of intermediate String objects and
keeping backward compatibility on the access logs files management (naming,
rotation, ...) with a new LogFactory.getLogger() approach would require
substantial efforts.

Cyrille


On Thu, Dec 12, 2013 at 2:56 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Cyrille,

 On 12/12/13, 3:56 AM, Cyrille Le Clerc wrote:
  Hello Christopher,
 
  Delegating to log4j/logback/java.util.logging could be an option
  but it would still greatly benefit of a refactoring to split the
  existing AccessLogValve into an AbstractAccessLogValve with the
  formatting logic and an AccessLogValve that would keep the logic to
  write in the file.
 
  With this split, the MyLoggingFrameworkAccessLogValve would
  extend the AbstractAccessLogValve.

 I'm not sure that's even necessary (since the current class could be
 merely changed-over to use a logger directly), although the
 AccessLogValve was designed to be fast which I believe it why it
 does not use a regular logger but rather its own write-to-disk logger.

  Regarding the existing Syslog implementations in Log4j and Logback,
  they don't yet allow user to customise the syslog header fields but
  I plan to propose to contribute these enhancements.

 Great!

  Finally, regarding the idea of injecting a logging framework jar in
  Tomcat classloader, I feel it makes things pretty difficult to
  understand with the risk of collision of the jars.

 I'm not sure that's much of a problem. First, Tomcat uses
 commons-logging and (modified) java.logging out of the box so they
 don't need to be added... just the logger that knows how to contact
 connect to syslog. Tomcat also supports using log4j which has a syslog
 appender already in it.

  As a conclusion, I would be very happy to contribute to the Tomcat
  project either the full SyslogAccessLogValve or just the split of
  the existing AccessLogValve into an AbstractAccessLogValve with the
  formatting logic and a AccessLogValve with the logic to write in
  files.

 I'll let others comment, of course.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSqcChAAoJEBzwKT+lPKRYK/kQAJ3EXU+AzaPFOFptiR4ORDad
 ouNxYec6VMQcsTbOUdQVvjPWFdXsXP370qLINR5rfXNabkrZH+xIgDiPqbwM1Uwd
 IritRUNeXdh6hSOPdXK1MDJx8lYfbopjYNC9DfP46lsOQZlU491RLN/eNW+UGkWA
 BsEu9Hk2LPwsIzdgpz7RCbuzgJmURitcpyAGtyHxkw6e/20lhvZo/SjkCGcGK3tS
 qqqWYPzoJBoWrkJYnaVi1eREcNW5mdx8kssFkdeNHSHLYyDzsb6LyrNWSDWqUYFC
 Hn0ej/NNFyJjW/I2X4MIvU30ZuhYw80Oa/ybYyP2Jss+l7gnLltS1ijeXmCoN7pn
 2JfPqHtpxNp4czQB9WfmgdUvHoYn2uMKt0lQJ13EHU/L6ATHW6zhdzGOJ1LSMfrz
 hPPS4VCxq8miE9gt+j+Q4MgguJxSTHcjlLuObWZifCqh8plWSKlyE8o50nzxn0NQ
 KtwUpsQUUlwha1PNJKWhX/XTBPYbRu0OG+aA+xrFPdJU//68ApXTICcPife05Bc0
 Et/VGgLtJt/q4KnQuIVK7uPD9dOOndMkKAhDSGCZ56TxdxWO0juR1j1lgCi+kC2C
 n0EfsuCe+JUvd5MWmBalcFno09w1tpbTSfxpspmIzwJ8Cx181P5ffDOG9lGlV2nN
 N8H6Bd+kajS9EH3BchTs
 =VgKF
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Cyrille Le Clerc
email  gtalk : clecl...@cloudbees.com / mob: +33-6.61.33.69.86 / skype:
cyrille.leclerc
CloudBees, Inc
www.cloudbees.com

Proposal to contribute a SyslogAccessLogValve to the Tomcat project

2013-12-11 Thread Cyrille Le Clerc

Dear Tomcat community,

We at CloudBees implemented a SyslogAccessLogValve that outputs the
access logs to a syslog server.

The support of Syslog is more detailed that what we can usually find
in java logging libraries as it allows to
* configure all the syslog header fields: appName, source hostname,
severity and facility
* format syslog message according the RFC 3164 and to RFC 5424

Would the Tomcat project be interested in such contribution?



This contribution is composed of:
* An object oriented model of a syslog message
* A Syslog UDP message sender
* Refactoring: split of the existing AccessLogValve into
** AbstractAccessLogValve: the logic to format the access logs
** AccessLogValve: the logic to write the access logs in rolling file
* The SyslogAccessLogValve that extends the new AbstractAccessLogValve
and relies on the Syslog message sender

It could be interesting in the future to:
* add a Syslog TCP sender (RFC 6587) and a TCP-TLS sender (RFC 5425)
* add a Syslog appender to java.util.logging


The existing code is available here, I have made few enhancement to
the code that would go inside Tomcat:
https://github.com/CloudBees-community/cloudbees-web-container-extras/tree/master/src/main/java/com/cloudbees/syslog
https://github.com/CloudBees-community/cloudbees-web-container-extras/tree/master/src/main/java/com/cloudbees/tomcat/valves

Please let me know if this contribution could interest the community,
I would then be happy to send a pull request if this format is
accepted or to submit a diff on bugzilla.

Cyrille

PS: I already signed an ICLA when I was a committer on Apache CXF and
I already contributed to Apache Tomcat (RemoteIpValve, RemoteIpFilter
and ExpiresFilter)

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: What monitoring do you use/recommend?

2011-04-21 Thread Cyrille Le Clerc

   Hello Gautam,

   I recommend you to have a look at Hyperic HQ (1). I had very good
experiences with it, including a big french telco operator which has
been using it for more than three years nearly 100 Tomcat JVMs.
   VMWare/SpringSource is investing a lot on Hyperic HQ, the Open
Source / Community edition is used in production by very serious
system administrators, it is possible to monitor your custom metrics
(JMX + Hyperic XML based plugins).


   If you want much more sophisticated monitoring, I have been very
happy with AppDynamics. More expensive but very detailed and powerful
business transactions oriented monitoring.

   Cyrille

(1) http://www.hyperic.com/
--
clecl...@xebia.fr
http://blog.xebia.fr


On Thu, Apr 21, 2011 at 5:25 PM, Gautam R Singh (gautsing)
gauts...@cisco.com wrote:

 Hi List,

 My team maintains a small Tomcat 6.x hosting environment for our group (
 intranet only) use. And its growing now (30+ production TC JVM
 instances). We haven't been doing any monitoring just the URL
 availability test .

 And now we are looking for options to monitor it better, we enabled
 remote JMX on all the  JVMs but our existing paid monitoring software
 isn't smart enough to use the  JMX values intelligently. At the moment
 we just monitor the JMX attribute values (heap memory, threads, gc etc)
 and it spits out pretty graphs in reports. We would really want
 something which lets us -- if Currentthreads  are 95% of maxthreads,
 send warn email or run this script.

 Don't want to deploy another war in each of those webapps dir and have
 30 urls to check, something central which can query these via JMX rmi 
 maybe generate pretty graphs like those in jconsole?

 Thanks!

 -
 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: HTTP connector to be aware of proxied SSL requests

2010-06-17 Thread Cyrille Le Clerc

Hello Matt,

I think the RemoteIpValve does what you need : it looks at http
headers filled in the request by preceding network components (layer 7
load balancer, ssl accelerator, etc) such as 'x-forwarded-for' to get
the real ip address and 'x-forwarded-proto' to get the http/https
protocol. A concept of internal/trusted incoming proxies is used to
decide weither the http headers can be trusted or not.

Configuration is detailed in the javadocs :
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
The documentation of RemoteIpValve has been enhanced in Tomcat 7 to
integrate the content of the java doc.

I wrote a blog post in french to explain how it works with detailed
diagrams here :
http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/

Basically, if you want to trust http header x-forwarded-for and
x-forwarded-proto coming from LB/web-server 192.168.0.10 and
192.168.0.11, the valve configuration will look like :

Server ...
...
Service name=Catalina
Connector ... /
Engine ...
!-- Process X-Forwarded-For to get remote address and
X-Forwarded-Proto to identify SSL requests --
Valve
className=org.apache.catalina.valves.RemoteIpValve
internalProxies=192\.168\.0\.10, 192\.168\.0\.11
protocolHeader=X-Forwarded-Proto /

!-- AccessLogValve must be declared after RemoteIpValve to
get the remote address and the scheme https/http --
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs pattern=common prefix=access_log.
resolveHosts=false suffix=.txt /

...
/Host
/Engine
/Service
/Server

Please note that you can simplify the configuration omitting
'internalProxies' attribute and rely on the default that trusts all
the class A, B C private IP addresses.

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson matt.peter...@une.edu.au wrote:

Hi All,

We have a hardware load balancer terminating SSL requests before making a
plain-text connection with Tomcat. So that all contexts are aware that the
request is actually a secure request, we have implemented the RemoteIpValve
with a LB injected header. This works well for our apps. However, we have
noticed that there is some processing of the request happening within the
connector, before the valves are processed. In particular, the redirecting
to URLs with a trailing slash. Because this processing is occurring before
the valves are processed the Connector still thinks that the original
request was a non-secure one, even though it was not. The result is that
requests to https://domain.name/context are redirected to
http://domain.name/context/ instead of to https://domain.name/context/. This
is not major, because our LB then redirects from http://domain.name/context/
to https://domain.name/context/ and all is good (except for the extra
redirect).

I can't find any documentation on the order of events for the Connector, so
I'm not sure what other decisions get made based on the request attributes,
but assume there are others.

Is there another solution to handling proxied SSL requests so that Catalina
as well as our apps are aware that the requests are secure??? One
possibility is to have two Connectors (1 using the secure, scheme and
serverPort attributes for secure and 1 for non-secure) and have the LB
connect to the appropriate Connector depending on the request. But this
effectively doubles the amount of config needed to be managed (2nd set of
config for LB + 2nd connector), which is considerable when dealing with 6 TC
clusters each with their own set of LB config.

Should I lodge an enhancement request for the Connector to become aware of
proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala
WebLogic)?

Cheers,

Matt.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Proposal : port mod_expires in java as ExpiresFilter Servlet Filter

2010-04-16 Thread Cyrille Le Clerc

   Hello Christopher,

   I imagine the project crew has been very busy these days. Do you
have feedbacks on the adaptations and explanations I did ? Is there
anything I could iterate on ?

   To rephrase my previous email :

* I reduced the number of comparison against 'nulls' as you suggested.
I did this introducing a method
'isEligibleToExpirationHeaderGeneration(request)' with several
intermediate 'return' statements ; I found it easier to code than to
use nested if/else statements.

* The reason why I introduced the complexity of trapping the
'onStartWriteResponseBody' event is that I tried my best to implement
in ExpiresFilter the same behavior as in Apache Httpd mod_expires.

   Cyrille

On Mon, Mar 29, 2010 at 8:32 PM, Cyrille Le Clerc clecl...@apache.org wrote:

 Thanks for your fast feedbacks Christopher,

 I updated the patch proposed on Bugzilla 48998 to include your advice
 to limit the number of null checks. The implementation I found is
 slightly different than your proposal but the idea remain the same.
 Please note that I only modified the patch and not yet
 ExpiresFilter.java on the google-code project as my priority is the
 Tomcat proposal.

 Regarding the simplification of generating expiration headers just
 after 'response.setContentType()' is called rather than after the
 first write in the response body, I didn't follow this way because
 applications could add/set 'Cache-Control' and/or 'Expires' header
 after invoking  'response.setContentType()'.

 My understanding is that the filter must work after
 'setContentType()', 'set/addHeader(Cache-Control, ...)' and
 'set/addHeader(Expires, ...)' have been called but we don't know
 which ones will be called and in which order they will be called.
 This is the reason why I unfortunately added the complexity to trap
 the 'onStartWriteResponseBody' event.

 Cyrille

 On Mon, Mar 29, 2010 at 3:20 PM, Christopher Schultz
 ch...@christopherschultz.net wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Cyrille,
 
  On 3/26/2010 12:43 PM, Cyrille Le Clerc wrote:
   I have proposed with bugzilla 48998 a port of Apache mod_expires in
   Java as ExpiresFilter Servlet Filter.
 
  Cool.
 
   I detailed a standalone version of this filter on
   http://code.google.com/p/xebia-france/wiki/ExpiresFilter . Moreover, I
   tried my best to provide very detailed javadocs and docs (in filter.html).
  
   The proposed contribution is slightly different than the standalone
   one because it uses Tomcat logging, few Servlet 3 enhancements and
   Tomcat engine in the test cases.
 
  I read-through your code on code.google.com and I can see a couple areas
  where I think improvements might be made:
 
  - - In getExpirationDate, you check for the local 'configuration' being
  null several times in a row. In each case, the configuration may be set
  given a different 'level' of configuration. If the configuration gets
  set, several checks must still be made to see if it is null. You could
  mail out early and avoid some of these checks like this:
 
  if(configuration == null) {
   configuration = ...;
 
   if(configuration == null) {
     // try another strategy
     configuration = ...;
 
     if(configuration == null) {
        ...
     }
   }
  }
 
  I think can save a bit of CPU time without much in the way of code
  complexity.
 
  - - You might be able to wrap the Response class and check for the setting
  of the Content-Type header, instead of wrapping the response in order to
  intercept the first buffer flush to the client. Do you think that would
  work? It certainly would remove a lot of complexity from your code.
 
  - -chris
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.10 (MingW32)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
  iEYEARECAAYFAkuwqQwACgkQ9CaO5/Lv0PDdwgCgrSHwmgUTDWybmk6/G1+AqNzY
  kCQAn0zVrQBARihaoQkfBJRtKYkjvsjs
  =kBWG
  -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

Proposal : Enhancing docs for RemoteIpValve and RemoteIpFilter

2010-03-30 Thread Cyrille Le Clerc

   Dear all,

   I would be very happy to enhance the docs of the RemoteIpValve (1)
and the RemoteIpFilter (2) if the project is interested.

   I was thinking about adding sample to explain
* the difference between the internal proxies list and the trusted
proxies list,
* how to handle https requests with x-forwarded-proto header,
* what are the values of x-forwarded-for and x-forwarded-by headers

   Many samples are already available in the javadocs (3), I would be
very happy to adapt them to the docs.

   Please let me know if this proposal is interesting.

   Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr

(1) http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote IP Valve
(2) will be available in Tomcat 7 in /config/filter.html
(3) 
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Proposal : port mod_expires in java as ExpiresFilter Servlet Filter

2010-03-29 Thread Cyrille Le Clerc

Thanks for your fast feedbacks Christopher,

I updated the patch proposed on Bugzilla 48998 to include your advice
to limit the number of null checks. The implementation I found is
slightly different than your proposal but the idea remain the same.
Please note that I only modified the patch and not yet
ExpiresFilter.java on the google-code project as my priority is the
Tomcat proposal.

Regarding the simplification of generating expiration headers just
after 'response.setContentType()' is called rather than after the
first write in the response body, I didn't follow this way because
applications could add/set 'Cache-Control' and/or 'Expires' header
after invoking  'response.setContentType()'.

My understanding is that the filter must work after
'setContentType()', 'set/addHeader(Cache-Control, ...)' and
'set/addHeader(Expires, ...)' have been called but we don't know
which ones will be called and in which order they will be called.
This is the reason why I unfortunately added the complexity to trap
the 'onStartWriteResponseBody' event.

Cyrille

On Mon, Mar 29, 2010 at 3:20 PM, Christopher Schultz
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Cyrille,

 On 3/26/2010 12:43 PM, Cyrille Le Clerc wrote:
  I have proposed with bugzilla 48998 a port of Apache mod_expires in
  Java as ExpiresFilter Servlet Filter.

 Cool.

  I detailed a standalone version of this filter on
  http://code.google.com/p/xebia-france/wiki/ExpiresFilter . Moreover, I
  tried my best to provide very detailed javadocs and docs (in filter.html).
 
  The proposed contribution is slightly different than the standalone
  one because it uses Tomcat logging, few Servlet 3 enhancements and
  Tomcat engine in the test cases.

 I read-through your code on code.google.com and I can see a couple areas
 where I think improvements might be made:

 - - In getExpirationDate, you check for the local 'configuration' being
 null several times in a row. In each case, the configuration may be set
 given a different 'level' of configuration. If the configuration gets
 set, several checks must still be made to see if it is null. You could
 mail out early and avoid some of these checks like this:

 if(configuration == null) {
  configuration = ...;

  if(configuration == null) {
    // try another strategy
    configuration = ...;

    if(configuration == null) {
       ...
    }
  }
 }

 I think can save a bit of CPU time without much in the way of code
 complexity.

 - - You might be able to wrap the Response class and check for the setting
 of the Content-Type header, instead of wrapping the response in order to
 intercept the first buffer flush to the client. Do you think that would
 work? It certainly would remove a lot of complexity from your code.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAkuwqQwACgkQ9CaO5/Lv0PDdwgCgrSHwmgUTDWybmk6/G1+AqNzY
 kCQAn0zVrQBARihaoQkfBJRtKYkjvsjs
 =kBWG
 -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: Question on Linux Tomcat Apache Server and Port Redirection for a robotics site

2010-03-15 Thread Cyrille Le Clerc

   Hello Melanie,

   I share André's vision :

#1 To get the root context http://www.robotronics.org/ forwarded to
Tomcat, the easiest way is to declare your java application as the
root context of your Tomcat (either naming it ROOT.war or declaring it
with path= in server.xml according to your deployment method).

#1.1 If you cannot rename your tomcat app to serve Tomcat's root
context, look at context rewriting ; it would look like :

ProxyPass / http://my-tomcat:9080/Robotronics
ProxyPassReverse /Robotronics http://www.robotronics.org/


#2 You can mix the approach #1 to serve most of the
http://www.robotronics.org/ content including the root context with
Tomcat with serving sub parts of the web site directly from Apache
Httpd or from other servers.

ProxyPreserveHost On
ProxyPass /handle/in/httpd/rather/than/in/tomcat !
ProxyPass / http://my-tomcat:9080/

#3 Some people are afraid about performance cost of serving static
content from Tomcat rather than from Apache Httpd. For such problems,
I feel the solution resides more in the usage of standard HTTP caching
header Expires and Cache-Control combined with mod_expires and
mod_disk_cache rather than in copying static resources on Apache
Httpd.

#4 I slightly disagree with André on asking Tomcat to listen on port
80 ; I am very reluctant to this approach as it requires to run the
JVM as root ; I prefer the iptables approach (well described in the in
the rimuhosting doc you referred - 1).

Hope this helps,

Cyrille

1) http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp#iptables
--
clecl...@xebia.fr
http://blog.xebia.fr


On Mon, Mar 15, 2010 at 11:37 AM, André Warnier a...@ice-sa.com wrote:

 Melanie wrote:

 Thanks Cyrille for the information. This looks like it's a quick fix but
 there is still another issue.

 The Tomcat Startup Page is now being served, but not the actual springapp
 J2EE web application that is located in the Tomcat directory ---
 /usr/java/tomcat-5.5/webapps/springapp

 Do you know the way to bring up the actual J2EE webpage instead of the
 Tomcat Startup Page when the URL
 http://www.robotronics.org is served by Apache and Tomcat?

 Melanie,

 backing up a little bit..

 According to your various posts, originally, you have, on the same host :

 - an Apache httpd, answering on http://www.robotronics.org (port 80), which 
 serves html and javascript documents
 - a Tomcat engine and an application in it, answering on 
 http://www.robotronics.org:9080/Robotronics (thus port 9080, and a URI 
 /Robotronics), but this application is located in the directory 
 /usr/java/tomcat-5.5/webapps/springapp.

 and you would apparently like that everything would answer to the URL
 http://www.robotronics.org (port 80).

 That is feasible, but the above is composed of several parts, and there are 
 several ways to configure the individual parts.
 So you have to be a bit systematic in the approach, and do one thing at a 
 time.

 A couple of questions to answer first are :
 1) do you want to leave the html and javascript part under the Apache httpd 
 server, or not ?
 2) do you need this Apache httpd server for other things, apart from this 
 specific case ?

 The reason for these questions is that the easiest and simplest setup would be
 - to move the html and javascript part onto the Tomcat server
 - to eliminate the Apache httpd server
 - to change the Tomcat server so that it responds to port 80 instead of port 
 9080
 - to change the Tomcat configuration so that your webapp application becomes 
 the default application of Tomcat, and thus answers to the URL
 http://www.robotronics.org, without the /Robotronics prefix.

 But, this simple setup would not be the right one if you want to keep the 
 front-end Apache httpd, because for example you need it for other things 
 (other virtual sites, other applications, etc..).
 In that case, we would then recommend some form of proxying between Apache 
 httpd and Tomcat.  And there are several possibilities there too.
 Which is why I mention the need to take this one bit at a time..


 -
 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: Question on Linux Tomcat Apache Server and Port Redirection for a robotics site

2010-03-15 Thread Cyrille Le Clerc

My mistake on port 80 without being root, I never used jsvc ; I relied
on startup.sh.

Cyrille

On Mon, Mar 15, 2010 at 1:53 PM, André Warnier a...@ice-sa.com wrote:
 Cyrille Le Clerc wrote:

 #4 I slightly disagree with André on asking Tomcat to listen on port
 80 ; I am very reluctant to this approach as it requires to run the
 JVM as root ;

 No, it does not, if you run the JVM under jsvc (commons-daemon).
 This is how most Linux packages nowadays set it up by default.

 But of course, you cannot run 2 servers at the same time listening on the
 same port. So if you want to have Tomcat handle port 80, then you cannot
 have Apache httpd listening to that same port at the same time.


 -
 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: getServerName returns 'localhost'

2010-03-03 Thread Cyrille Le Clerc

Hello Ivan,

The headers x-forwarded-for, x-forwarded-host and x-forwarded-server
are typically added by Apache Httpd mod_proxy (1).

It seems that you use Apache Httpd mod_proxy in front of your Tomcat,
both located on the same server (this is the reason why get
localhost).

Your solution may be to look at the ProxyPreserveHost On directive
in Apache configuration (2).

If you use It would look like :

ProxyPreserveHost On
ProxyPass /mypath http://localhost:8080/mypath

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

(1) see http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers
(2) see http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypreservehost


On Wed, Mar 3, 2010 at 5:09 PM, vgud ivan.gudi...@yahoo.com wrote:

 I tried to log all request headers and notice three interesting headers:

 x-forwarded-for : 10.0.0.24
 x-forwarded-host : myRealDomain.com
 x-forwarded-server : my.server.ip.address

 So, tomcat(or someone else) does some forwarding and attach those headers on
 request?

 If so where and how it is configured?


 n828cl wrote:
 
  From: André Warnier [mailto:a...@ice-sa.com]
  Subject: Re: getServerName returns 'localhost'
 
  public java.lang.String getServerName()
       Returns the host name of the server to which the request was sent.
  It is the value of the part before : in the Host header value, if
  any, or the resolved server name, or the server IP address.
       Returns:
           a String containing the name of the server
 
  That does not seem to work in his case.
 
  Does it only work when the Host or Alias tags with the
  corresponding names are set ?
 
  The code shows that the HOST header is being used by getServerName().
  Testing with the RequestDumperFilter enabled in examples/WEB-INF/web.xml
  shows that it works as documented; here's a portion of the output from
  Tomcat running on my desktop with the default Host name of localhost:
          serverName=usrv-caldarcr.na.uis.unisys.com
          serverPort=8080
 
  It appears the OP has something else going on that's interfering with the
  target IP address.  (Internal routing, perhaps?)
 
   - 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.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

 --
 View this message in context: 
 http://old.nabble.com/getServerName-returns-%27localhost%27-tp27767838p27770177.html
 Sent from the Tomcat - User mailing list archive at Nabble.com.


 -
 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: Apache 2.2 and TomCat 6.0 using SSL

2010-02-26 Thread Cyrille Le Clerc

My mistake,

I meant x-forwarded-proto rather than x-forwarded-for.

Here is a sample of configuration where Apache adds the header
X-Forwarded-Proto and Tomcat RemoteIpValve handles it.

APACHE CONFIGURATION
=
# 'myapplication' cluster
Proxy balancer://myapplication
BalancerMember http://node-1:8080 route=node-1
...
BalancerMember http://node-n:8080 route=node-n
/Proxy
VirtualHost default:80
# Declare X-Forwarded-Proto as http for incoming request
RequestHeader set X-Forwarded-Proto http
...
/VirtualHost

VirtualHost default:443
# mod_ssl configuration
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /private/etc/apache2/server.crt
SSLCertificateKeyFile /private/etc/apache2/server.key

# Overwrite X-Forwarded-Proto declaration for port 443, request are https
RequestHeader set X-Forwarded-Proto https
...
/VirtualHost
..
ProxyPreserveHost On
ProxyPass /mypath balancer://myapplicationssl/mypath stickysession=JSESSIONID

TOMCAT CONFIGURATION
=

Server ...
...
Service name=Catalina
Connector ... /
Engine ...
!-- Process x-Forwarded-For to get remote address and
X-Forwarded-Proto to identify SSL requests --
Valve className=org.apache.catalina.valves.RemoteIpValve
protocolHeader=X-Forwarded-For /

...
/Host
/Engine
/Service
/Server

Hope this helps,

Cyrille

On Thu, Feb 25, 2010 at 5:44 PM, Cyrille Le Clerc clecl...@apache.org wrote:

Hello,

We tried to detail precisely on a blog post named Tomcat, SSL,
communications sécurisées et X-Forwarded-Proto (1) different
solutions to handle SSL with Tomcat including decrypting https on the
Apache layer. It is written in french but there are many schemas and
it is google translate friendly.

My preferred solution is to use the RemoteIpValve in Tomcat in
addition with the X-Forwarded-For http header set in Apache httpd.
Another solution is to create two connectors in Tomcat, a non secured
one and a secured one.

Please note that RemoteIpValve has been introduced in version 6.0.24
of Tomcat and is available for previous versions in a separate jar
(2).

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr

(1)
http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/
(2) http://code.google.com/p/xebia-france/wiki/RemoteIpValve

On Thu, Feb 25, 2010 at 4:56 PM, sikorsky rsm...@sikorsky.com wrote:

I'm new to Apache 2.2 and TomCat 6.0. I thought I could use SSL on my
Apache
web server and not need to have SSL on my TomCat applications. Especially
since they are both on the same server. I installed an Entrust Cert on my
Apache webserver and it works fine with https. When I redirect to the
TomCat servlet I get a 404. If I switch to http everything works fine.
Shouldn't I be able to use https/443on my web server and http/8080 on the
app server without issue? How?
--
View this message in context:
http://old.nabble.com/Apache-2.2-and-TomCat-6.0-using-SSL-tp27714427p27714427.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache 2.2 and TomCat 6.0 using SSL

2010-02-25 Thread Cyrille Le Clerc

Hello,

Please note that RemoteIpValve has been introduced in version 6.0.24
of Tomcat and is available for previous versions in a separate jar
(2).

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr

(1)
http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/
(2) http://code.google.com/p/xebia-france/wiki/RemoteIpValve

On Thu, Feb 25, 2010 at 4:56 PM, sikorsky rsm...@sikorsky.com wrote:

I'm new to Apache 2.2 and TomCat 6.0. I thought I could use SSL on my Apache
web server and not need to have SSL on my TomCat applications. Especially
since they are both on the same server. I installed an Entrust Cert on my
Apache webserver and it works fine with https. When I redirect to the
TomCat servlet I get a 404. If I switch to http everything works fine.
Shouldn't I be able to use https/443on my web server and http/8080 on the
app server without issue? How?
--
View this message in context:
http://old.nabble.com/Apache-2.2-and-TomCat-6.0-using-SSL-tp27714427p27714427.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: GC(JVM Heap usage) tool

2010-02-08 Thread Cyrille Le Clerc

Hello Paulwintech,

I suggest you to have a look at Hyperic. It is a very interesting tool and
you can extend it quite easily with custom JMX MBeans.

Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr

On Mon, Feb 8, 2010 at 2:01 PM, Leon Rosenberg 
rosenberg.l...@googlemail.com wrote:

 Hi,

 if you mean this kind of monitoring:


 http://moskito.anotheria.net/moskitodemo/mui/mskShowProducersByCategory?pCategory=memory

 than all you need is here:

 http://infra.anotheria.net/confluence/display/MSK/HowTo+Embed+Moskito+WebUI+In+Your+Application

 regards
 Leon

 On Mon, Feb 8, 2010 at 6:07 AM, Paulwintech paulwint...@gmail.com wrote:
 
  Hello All,
 
 I need a java tool that can monitor my JVM heap usage, Since
  intermediately i get GC free memory issue. Except JVM meter - Any other
 java
  tools that will help me to troubleshoot my intermediate issue.
 
 
  Thanks
  Paulwintech
  --
  View this message in context:
 http://old.nabble.com/GC%28JVM-Heap-usage%29-tool-tp27495361p27495361.html
  Sent from the Tomcat - User mailing list archive at Nabble.com.
 
 
  -
  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: Threadlocal problem

2010-02-02 Thread Cyrille Le Clerc

Hello,

Your threadLocal variable is created by the reflectionToString feature
of Jakarta Commons Lang ToStringBuilder (1).

This thread local variable seems to be used to prevent infinite
recursion when ToStringBuilder traverse the objects.

I didn't see yet a way (servlet filter, etc) to cleanup this ThreadLocal.

Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr

(1)
http://fisheye6.atlassian.com/browse/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java?r=594386#l136

On Tue, Feb 2, 2010 at 2:44 PM, Mark Thomas ma...@apache.org wrote:

On 02/02/2010 13:31, Malcolm Warren wrote:
SEVERE: A web application created a ThreadLocal with key of type
[org.apache.commons.lang.builder.ToStringStyle$1] (value
[org.apache.commons.lang.builder.tostringstyl...@66a37d72]) and a value
of type [java.util.HashSet] (value [[]]) but failed to remove it when
the web application was stopped. To prevent a memory leak, the
ThreadLocal has been forcibly removed.

I get this message with every hot redeploy, which is a little worrying.
Anybody know what it's about?

The message says it all. Something created a ThreadLocal but didn't
clean it up. Tomcat cleaned it up to prevent a memory leak.

This started with the latest Tomcat 6 version: 6.0.24.
I'm pleased with this new version because it also pointed out politely
that I hadn't closed a thread I'd opened.

This is all part of the new memory leak protection added for 6.0.24. It
is good to hear that people are finding it useful.

I've fixed my Thread but I still get the message shown at the beginning
of this email.

I don't use ThreadLocal in my code at all, so it's Tomcat who's creating
this ThreadLocal for some reason, but since it's not mine it's something
I can't do much about, presumably.

It isn't Tomcat's (Tomcat doesn't ship with commons-lang) so I am pretty
sure it is yours. Chances are it isn't something you are doing directly
but maybe something a library you are using is doing?

If a library is adding a ThreadLocal to a request processing thread it
*must* remove it before the request completes to avoid a potential
memory leak. If it doesn't, I would argue that is a bug in the library.
At a stretch, if the library provides a mechanism to clean these up on
web app shutdown that is just about OK but that could would need to be
carefully coded.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

JMX Client UnmarshalException with JmxRemoteLifecycleListener and useLocalPorts=true

2010-01-25 Thread Cyrille Le Clerc

   Dear all,

   I faced a problem enabling JmxRemoteLifecycleListener with
useLocalPorts=true : my hyperic agent fails to connect with an
UnmarshalException caused by a ClassNotFoundException on
JmxRemoteLifecycleListener$RmiClientLocalhostSocketFactory (details below).
   The workaround I found is to copy catalina-jmx-remote.jar under
$HYPERIC_AGENT_HOME/bundles/agent-4.1.2-1053/lib/ .

   However, for a long term fix, I would find interesting to have
useLocalPorts=true working out-of-the-box with tools like Hyperic HQ.
Surprisingly, this problem occurs with hyperic agent but not with VisualVM ;
I didn't have the time to investigate?

   I don't know yet if the long term fix is on hyperic-agent or tomcat side.
I just wanted to share the issue and the workaround with the community as I
didn't find anything on Google.

   If someone has insights on this problem, I am very interested.

   Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr


Environment : apache-tomcat-6.0.24, Java HotSpot(TM) Server VM (build
11.3-b02, mixed mode), hyperic-agent-4.1.2-1053, Linux 2.6.9-78.ELlargesmp

HYPERIC AGENT ERROR MESSAGE

2010-01-25 16:48:49,592 ERROR [Thread-0] [MeasurementCommandsService] Error
getting real time measurement: Error contacting resource: Can't connect to
MBeanServer [{jmx.username=system,
jmx.url=service:jmx:rmi:///jndi/rmi://localhost:14008/jmxrmi}]:
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.CommunicationException [Root exception is
java.rmi.UnmarshalException: error unmarshalling return; nested exception
is:
java.lang.ClassNotFoundException:
org.apache.catalina.mbeans.JmxRemoteLifecycleListener$RmiClientLocalhostSocketFactory
(no security manager: RMI class loader disabled)]

Re: Changing request address to x-forwarded-for

2010-01-06 Thread Cyrille Le Clerc

   Hello Mohit,

   You can use this RemoteIpValve (1) on Tomcat 6.0.18, you just have
to drop the xebia-tomcat-extras-1.0.0.jar (2) in your Tomcat lib
directory.

   This version is being used on several web sites including high volume ones.

   If you can wait few days, a new version of Tomcat 6 including this
valve will hopefully be released very soon ; vote has started on the
tomcat-dev mailing list just before christmas.

   Don't hesitate to ask questions if the docs aren't clear enough,

   Hope this helps,

   Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

(1) http://code.google.com/p/xebia-france/wiki/RemoteIpValve
(2) http://xebia-france.googlecode.com/files/xebia-tomcat-extras-1.0.0.jar

On Wed, Jan 6, 2010 at 4:52 PM, Mohit Anchlia mohitanch...@gmail.com wrote:

 I found this site

 http://code.google.com/p/xebia-france/wiki/RemoteIpValve

 Can I directly download and install it in 6.0.18?

 On Wed, Jan 6, 2010 at 7:41 AM, Mohit Anchlia mohitanch...@gmail.com wrote:
  Could you please point me to an example of how I can do this? We are
  using apache-tomcat-6.0.18
 
  On Tue, Jan 5, 2010 at 11:41 PM, Mark Thomas ma...@apache.org wrote:
  On 06/01/2010 04:14, Mohit Anchlia wrote:
  tomcat 6:
 
  Is it possible to inject or change remote address to what's in
  x-forwaded-for in http header such that when Servlet received the
  request it's already in the request.getRemoteAddress()? Otherwise
  we'll need to make a urgent change to read from the HTTP header. We
  didn't realize it earlier since we are using F5 LTM.
 
  The next release of Tomcat 6 will include a new valve (RemoteIpValve) to
  do exactly this. If you can't wait for the next 6.0.x release (should be
  soon - hopefully next week or so) then you can always use that as the
  basis to write your own valve. Alternatively, Tomcat 7 also has a filter
  that does the same thing that you could use as a startign point.
 
  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


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How To Get MBean Server of Apache Tomcat.

2009-12-08 Thread Cyrille Le Clerc

   Hello Ben,

   Tomcat relies on the out-of-the-box feature of the JVM to make the
MBeanServer accessible to other processes (possibly located on other
servers).

   You have to add the following parameters to the Tomcat startup
command line :
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=6969 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false

JMX listen port 6969 is configurable.

All details at http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

On Tue, Dec 8, 2009 at 1:34 PM, Ben Katz ben.k...@gmail.com wrote:

 Hi,
 I use ManagementFactory.getPlatformMBeanServer() from within Apache Tomcat
 and from a regular JAR file (outside the scope of apache).
 I think (And correct me if im wrong) I'm getting different MBean Servers.
 My question is - How Do I reach the Tomcat mbean server from outside or
 alternatively, how do I register the MBeans from inside apache with the
 outside world MBean server.
 The first option (Reach the Tomcat mbean server from the outside) is
 preferable.
 Thanks!!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How To Get MBean Server of Apache Tomcat.

2009-12-08 Thread Cyrille Le Clerc

   Hello Ben,

   You are right, Tomcat, with these standard JVM JMX parameters,
creates a new MBeanServer that is not the platform mbean server and
that does not contain the JVM Mbeans (1). I didn't take the time to
figure out wether it was the JVM or Tomcat behavior.

   On production, we use Hyperic declaring two servers : a JVM
server and a Apache Tomcat 6.0 Server. I must admit it is not the
most elegant but it does the job :-)

   For my JMX troubleshooting on Tomcat, I use JVisualVM (with the
MBeans plugin) and a few JSP pages I drop in my web apps :
http://cyrille-leclerc.googlecode.com/svn/trunk/cyrille/src/main/webapp/tools/jmx/mbeans.jsp
http://cyrille-leclerc.googlecode.com/svn/trunk/cyrille/src/main/webapp/tools/jmx/mbean.jsp
http://cyrille-leclerc.googlecode.com/svn/trunk/cyrille/src/main/webapp/tools/jmx/platformMbeans.jsp
   I mostly use the two firsts jsps as I mostly monitor Tomcat and
application specific MBeans, not very much JVM MBeans (except via
Hyperic).

   Hope this helps,

   Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

(1) : java.lang:type=Runtime, java.lang:type=OperatingSystem,
java.lang:type=Threading, java.lang:type=Memory

On Tue, Dec 8, 2009 at 4:07 PM, Ben Katz ben.k...@gmail.com wrote:
 Hi Cyrille,

 Thanks for you reply.
 I have actually done what you suggested but that does not relate to the
 problem.

 To better Illustrate I will give this example:

 If I run the code below from a servlet in Tomcat I will get a list of
 domains:
        String[] domains =
 ManagementFactory.getPlatformMBeanServer().getDomains();

        for (int i =0; i  domains.length;i++)
        {
            System.out.println(domains[i]);
        }

 If I run the same code from a generic java application I will get a
 different list of domains.

 This means that the platform MBean server is different inside Tomcat.
 What I would like to do is to reach that server, probably by replacing
 ManagementFactory.getPlatformMBeanServer().getDomains(); with something
 else.

 Thanks again,
 Ben.


 On Tue, Dec 8, 2009 at 15:00, Cyrille Le Clerc clecl...@xebia.fr wrote:

   Hello Ben,

   Tomcat relies on the out-of-the-box feature of the JVM to make the
 MBeanServer accessible to other processes (possibly located on other
 servers).

   You have to add the following parameters to the Tomcat startup
 command line :
    -Dcom.sun.management.jmxremote \
    -Dcom.sun.management.jmxremote.port=6969 \
    -Dcom.sun.management.jmxremote.ssl=false \
    -Dcom.sun.management.jmxremote.authenticate=false

 JMX listen port 6969 is configurable.

 All details at http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

 Hope this helps,

 Cyrille

 --
 Cyrille Le Clerc
 clecl...@xebia.fr
 http://blog.xebia.fr

 On Tue, Dec 8, 2009 at 1:34 PM, Ben Katz ben.k...@gmail.com wrote:
 
  Hi,
  I use ManagementFactory.getPlatformMBeanServer() from within Apache
 Tomcat
  and from a regular JAR file (outside the scope of apache).
  I think (And correct me if im wrong) I'm getting different MBean Servers.
  My question is - How Do I reach the Tomcat mbean server from outside or
  alternatively, how do I register the MBeans from inside apache with the
  outside world MBean server.
  The first option (Reach the Tomcat mbean server from the outside) is
  preferable.
  Thanks!!

 -
 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: Advise on configuring SSL

2009-11-25 Thread Cyrille Le Clerc

   Hello CBy,

   My preference to handle SSL at the Apache Httpd level is to insert
a header x-forwarded-proto=http|https in Apache with mod_header, to
transmit the request in clear http to tomcat and then to intercept
this x-forwarded-proto header in Tomcat with the RemoteIpValve.
   This valve will be integrated in Tomcat's distribution in version
6.0.21 and is currently available on a Google Code Project (1).

   Another solution is to introduce a second HTTP connector in Tomcat
with the attributes secure=true and scheme=https. Even if this
connector uses HTTP instead of HTTPS, the connector attributes will
set request.isSecure() to true and request.getScheme() to https.

   I have written a very detailed document Tomcat, SSL, secure
communications and X-Forwarded-Proto (2) that explains solutions to
handle HTTPS at the Tomcat, Apache Httpd and Load Balancer layers. The
document is written in french but the google translation is quite good
(3).

   Hope this helps,

   Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

(1) http://code.google.com/p/xebia-france/wiki/RemoteIpValve
(2) 
http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/
(3) 
http://translate.google.com/translate?js=yprev=_thl=enie=UTF-8u=http%3A%2F%2Fblog.xebia.fr%2F2009%2F11%2F13%2Ftomcat-ssl-communications-securisees-et-x-forwarded-proto%2Fsl=frtl=en

On Wed, Nov 25, 2009 at 9:43 AM, CBy tom...@byrman.demon.nl wrote:
 Hi,

 In my current working environment, Tomcat 6.0.18 is behind Apache. I don't
 know why they chose this setup, because Apache only acts as a proxy, it
 doesn't host anything. I do have experience in setting up SSL for
 stand-alone Tomcat, but have no experience with Apache whatsoever. Since I
 do have administrative rights for Tomcat, but not for Apache, I was thinking
 of letting Tomcat handle SSL. Is that sensible or is it better to configure
 this with Apache in this case?

 CBy

 -
 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: Tomcat Https loadbalancing??

2009-11-25 Thread Cyrille Le Clerc

Hello,

As Ronald said, we made some drawings on a detailed document
Tomcat, SSL, secure communications and X-Forwarded-Proto (1) that
explains solutions to handle HTTPS at the Tomcat, Apache Httpd and
Load Balancer layers. The document is written in french but the google
translation is quite good (2).

My preference is to use a level 7 load balancer in front of Apache
httpd servers with mod_proxy_http+mod_proxy_balancer and then Tomcat
servers. Of course, this topology is not always the best one but is
very often relevant.

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

(1)
http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/
(2)
http://translate.google.com/translate?js=yprev=_thl=enie=UTF-8u=http%3A%2F%2Fblog.xebia.fr%2F2009%2F11%2F13%2Ftomcat-ssl-communications-securisees-et-x-forwarded-proto%2Fsl=frtl=en

On Wed, Nov 25, 2009 at 11:45 AM, Ronald Klop
ronald-mailingl...@base.nl wrote:
Always make a drawing.

client - https - tcp-loadbalancer - still same https connection-
multiple tomcats

client - https - http-loadbalancer (Apache, proxy) - new ajp/http(s)
connection- multiple tomcats

Normally the loadbalancer and tomcats are in the same private network. It is
your choice if that is secure enough. In the end the data is unencrypted in
the database I guess, so normally you trust your own network.

Ronald.

Op woensdag, 25 november 2009 10:18 schreef jkv j.kumara...@gmail.com:

Hello,

We are using Tomcat 6.0 and running HTTPS (enabled SSL). The number of
requests has grown up and we have decided to do go for clustering and
loadbalancing. We have decided to go for Apache and mod_proxy/mod_jk
loadbalacing. My certificate resides in Tomcat.
In order to loadbalance HTTPS request using Apache and mod_proxy/mod_jk,
should I configure Apache to handle HTTPS and tell it about my certificate
details?
While loadbalancing I understand that http/https request to Apache is
converted to ajp and tunneled to Tomcat, so is ajp protocol secure? should
I
enable SSL in tomcat to handle this request?
Should I have two copies of my certificate files if Apache and Tomcat
reside
on two different physical machines(Horizontal Clustering)?

I searched the forums and they are too advanced for my question. I am
really
new to clustering and load balancing and any help is deeply appreciated.
Thanks in advance.

Regards
jkv
--
View this message in context:
http://old.nabble.com/Tomcat-Https-loadbalancing---tp26509573p26509573.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Https loadbalancing??

2009-11-25 Thread Cyrille Le Clerc

Hello David,

Nice if you've got that sort of money.

I will go further, I feel the price of the famous hardware load
balancers is completely excessive in comparison with the other
components we use on production.
It is very common to see on production small servers (cheap dual x86
processors, cheap Linux, free JVM, free Tomcat/JBoss/Jetty, free
SpringFramework, free Hibernate, ...) and in front of them hardware
load balancers that cost more than 50 K USD.

I feel open source will come to load balancers as it came to operating
systems, application servers or database servers. Products like HA
Proxy are very appealing for inexpensive load balancing, they will fit
many production requirements.

I found interesting docs about inexpensive load balancing :
- Making applications scalable with Load Balancing by Willy Tarreau,
the father of HA Proxy
http://1wt.eu/articles/2006_lb/
- loadbalancing.org FAQ : a provocative opinion
http://www.loadbalancing.org/

it is quite cool because you can off-load the https part

Look at Willy Tarreau's Making applications scalable with Load
Balancing, he offloads SSL for almost free with a neat architecture.

Personally i prefer mod_proxy_ajp with the balancing as well.

I am preparing a blog post on AJP versus HTTP :-) My preference goes
to HTTP because it has always been enough for my needs, even on high
volume web sites, it is standard, network admins knows this protocol,
all the network device can speak it, I can troubleshoot it with telnet
and curl, ... :-)

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

On Wed, Nov 25, 2009 at 12:09 PM, David Cassidy da...@twocats.co.uk wrote:
Cyrille,

Nice if you've got that sort of money.
it is quite cool because you can off-load the https part
so some custom hardware - again cool if you've got the money

Personally i prefer mod_proxy_ajp with the balancing as well.

On 25/11/09 10:57, Cyrille Le Clerc wrote:

Hello,

Hope this helps,

Cyrille

--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr

On Wed, Nov 25, 2009 at 11:45 AM, Ronald Klop
ronald-mailingl...@base.nl wrote:

Always make a drawing.

client - https - tcp-loadbalancer - still same https connection-
multiple tomcats

client - https - http-loadbalancer (Apache, proxy) - new
ajp/http(s)
connection- multiple tomcats

Normally the loadbalancer and tomcats are in the same private network. It
is
your choice if that is secure enough. In the end the data is unencrypted
in
the database I guess, so normally you trust your own network.

Ronald.

Op woensdag, 25 november 2009 10:18 schreef jkvj.kumara...@gmail.com:

Hello,

We are using Tomcat 6.0 and running HTTPS (enabled SSL). The number of
requests has grown up and we have decided to do go for clustering and
loadbalancing. We have decided to go for Apache and mod_proxy/mod_jk
loadbalacing. My certificate resides in Tomcat.
In order to loadbalance HTTPS request using Apache and mod_proxy/mod_jk,
should I configure Apache to handle HTTPS and tell it about my
certificate
details?
While loadbalancing I understand that http/https request to Apache is
converted to ajp and tunneled to Tomcat, so is ajp protocol secure?
should
I
enable SSL in tomcat to handle this request?
Should I have two copies of my certificate files if Apache and Tomcat
reside
on two different physical machines(Horizontal Clustering)?

I searched the forums and they are too advanced for my question. I am
really
new to clustering and load balancing and any help is deeply appreciated.
Thanks in advance.

Regards
jkv
--
View this message in context:

http://old.nabble.com/Tomcat-Https-loadbalancing---tp26509573p26509573.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
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

Re: Cannot set remote address in valve (Tomcat 5.5)

2009-10-21 Thread Cyrille Le Clerc

   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: Valves being converted to Filters?

2009-10-20 Thread Cyrille Le Clerc

Hello Henri,

I was referring to public information such as :
- Google Summer Of Code 2009, project Convert current Tomcat valves
to Servlet Filters : http://wiki.apache.org/tomcat/SummerOfCode2009
and the various associated emails on Tomcat dev mailing list.
- Mark Thomas post on Tomcat users mailing list : ...47330 is on the
todo list but my current plan is to implement it as a Filter rather
than a valve. (1)

However, my understanding is not that pluggable 'interceptors' will
be removed from the container, just that the Valve API will be
replaced with a Filter API. I feel interfaces (HttpServletRequest
HttpServletResponse) will be much more easy to manipulate than the
current implementations (Request, Response).

Hopr this clarifies my message,

Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr cyri...@cyrilleleclerc.com
http://blog.xebia.fr

(1)
http://www.nabble.com/Re%3A-Cannot-set-remote-address-in-valve-%28Tomcat-5.5%29-p25632043.html

On Tue, Oct 20, 2009 at 10:38 PM, Eric B. ebe...@hotmail.com wrote:

Hi,

I was looking at Bug 47330
(https://issues.apache.org/bugzilla/show_bug.cgi?id=47330) which is a filter
/ valve implementation of a Httpd's mod_remoteip module. What concerned me
is a comment by the submitter at the very bottom of the report:

... As Tomcat valves are currently being converted into Servlet Filter (1),
here is
a Servlet Filter implementation...

Is this true? Is Tomcat moving away from valves and towards filters in the
next version(s)? Is there a specific reason for this?

Although I love filters, I find that valves have a very specific need within
the container as well; it allows you to configure the container
independently of the application. If everything is moving to filters, that
would require me to modify the app everytime I want the container to behave
slightly differently.

Am I misunderstanding the comment, or is the submitter mis-informed?

Thanks,

Eric

-
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)

2009-10-11 Thread Cyrille Le Clerc

   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)

2009-10-09 Thread Cyrille Le Clerc

   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)

2009-10-09 Thread Cyrille Le Clerc

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)

2009-10-08 Thread Cyrille Le Clerc

   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)

2009-10-05 Thread Cyrille Le Clerc

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: Secure jsessionid cookie : request.scheme==https versus request.secure == true

2009-06-23 Thread Cyrille Le Clerc

   Thanks for your reply Mark,

   I exposed this Valve + RequestFacade subclassing scenario to the other
guys on my project and we prefer not to modify Tomcat internals. We are
currently hesitating between introducing a ServletFilter and subclassing
org.springframework.security.securechannel.SecureChannelProcessor. We use
the second on production today, I added the small piece of code at the end
of this email for the people who would be intesrested.

   Cyrille
--
Cyrille Le Clerc
cyrille.lecl...@pobox.com clecl...@xebia.fr
http://blog.xebia.fr


public class TrustedRemoteAddressesEnabledSecureChannelProcessor extends
SecureChannelProcessor implements ChannelProcessor {

private final Logger logger =
Logger.getLogger(TrustedRemoteAddressesEnabledSecureChannelProcessor.class);

private Pattern[] trustedRemoteAddresses = new Pattern[] {
Pattern.compile(10\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}),
Pattern.compile(192\\.168\\.\\d{1,3}\\.\\d{1,3}),
Pattern.compile(169\\.254\\.\\d{1,3}\\.\\d{1,3}),
Pattern.compile(127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})
};

public void setSecuredRemoteAddresses(ListString
securedRemoteAddressesAsString) {
ListPattern newSecuredRemoteAddresses = new ArrayListPattern();
for (String securedRemoteAddr : securedRemoteAddressesAsString) {

newSecuredRemoteAddresses.add(Pattern.compile(securedRemoteAddr));
}
trustedRemoteAddresses = newSecuredRemoteAddresses.toArray(new
Pattern[0]);
}

@Override
public void decide(FilterInvocation invocation,
ConfigAttributeDefinition config) throws IOException, ServletException {

final boolean isSecureRemoteAddr =
matchOne(invocation.getHttpRequest().getRemoteAddr(),
trustedRemoteAddresses);

if (logger.isDebugEnabled()) {
logger.debug(Decide for  + invocation.getFullRequestUrl() + ,
request.remoteAddr=
 + invocation.getHttpRequest().getRemoteAddr() + ,
isSecureRemoteAddr= + isSecureRemoteAddr);
}

HttpServletRequestWrapper requestWrapper = new
HttpServletRequestWrapper(invocation.getHttpRequest()) {
@Override
public boolean isSecure() {
return super.isSecure() || isSecureRemoteAddr;
}
};
FilterInvocation filterInvocationWrapper = new
FilterInvocation(requestWrapper, invocation.getResponse(),
invocation.getChain());
super.decide(filterInvocationWrapper, config);
}

public static boolean matchOne(String str, Pattern... patterns) {
for (Pattern pattern : patterns) {
if (pattern.matcher(str).matches()) {
return true;
}
}
return false;
}
}


On Tue, Jun 23, 2009 at 11:45 AM, Mark Thomas ma...@apache.org wrote:

 Cyrille Le Clerc wrote:
  Thank you for the clarification Mark.
 
  Depending on where the session is created, you might be able to use a
  filter to wrap your response and modify the secure attribute of any
  cookies as they are added to the response.
 
  I am sorry to bother you but I don't see how I could wrap the class
  o.a.c.connector.Response whose method addCookieInternal(cookie)  is
  called by o.a.c.connector.Request.doGetSession(boolean)  to create the
  JSESSIONID cookie.

 Sorry, my bad. It was late and I wasn't thinking clearly.

  If all this is to complex, I will fall back to another approach that
  is to do pattern matching (10.*) on request.remoteAddr to flag
  RequestFacade.secure=true if the requests come from my secured network
  area. This will let request.secure=false if request.scheme=http and
  thus have non-secure JSESSIONID cookies.
  I tested with a valve called SecuredRemoteAddressesValve (1) that I
  precede of RemoteIpValve (2) to process the x-forwarded-for header to
  find the real remoteAddr and this works fine.

 That sounds like a good solution to me. Valves were the other area I was
 going to suggest you investigate.

 Mark



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Secure jsessionid cookie : request.scheme==https versus request.secure == true

2009-06-22 Thread Cyrille Le Clerc

Hello,

My usecase may have not been clear enough :

The internal over http connector : secure = true, scheme = http
doesn't behave has I would like for stateful requests because Tomcat
generates a secure JSESSIONID cookie even if the configured scheme is
http rather than https.

Due to this secure JSESSIONID cookie for non SSL http requests,
clients like Apache Http Client won't retransmit the cookie for
between requests.

I hope my usecase is clearer.

Cyrille

On Sun, Jun 21, 2009 at 12:52 PM, Cyrille Le Clerc
cyrille.lecl...@pobox.com wrote:

Hello,

I am interested in using the secure attribute of Tomcat
connectors for non https/ssl requests. However, the ssl only
JSESSIONID cookie mechanism currently relies on request.secure ==
true rather than on request.scheme == https (1). A confusion on
secure vs. https seems to come from the fact that cookie.secure ==
true is interpreted by most http clients as cookie.sslOnly == true.
Due to this behavior, I don't see how I can use connector.secure =
true without connector.scheme = https.

Could we imagine an evolution of Tomcat to generate secure session
cookies if request.scheme == https rather than on request.secure ==
true ? I would be very pleased to propose a patch.

My usecase is : an application receives requests from both the
internet and from other servers of my data center (same trusted zone).
The requests coming from the internet may use http or https when
internal request use http (for security and CPU consumption reasons).
The application's web services require a secure channel (https from
the internet or http from the trusted zone).
If Tomcat handled secure session cookies on request.scheme ==
https rather than request.secure == true, I would handle this with
three connectors thanks to the nuance between the secure and
scheme attributes of the connectors :
- external over http connector : secure = false, scheme = http
- external over https/ssl connector : secure = true, scheme = https
- internal over http connector : secure = true, scheme = http
Today, I handle this in the application wrapping the Http Servlet
Request to declare secure requests whose remoteAddr matches the 10.*
block.

Cyrille

(1) See
http://fisheye6.atlassian.com/browse/tomcat/trunk/java/org/apache/catalina/connector/Request.java?r=HEAD#l2367
(2) web browsers, Apache Commons Http client, etc

--
Cyrille Le Clerc
cyrille.lecl...@pobox.com clecl...@xebia.fr
http://blog.xebia.fr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Secure jsessionid cookie : request.scheme==https versus request.secure == true

2009-06-22 Thread Cyrille Le Clerc

   Thanks for your response Christopher,

  Could we imagine an evolution of Tomcat to generate secure session
  cookies if request.scheme == https rather than on request.secure ==
  true ? I would be very pleased to propose a patch.

 Do you have a reason to set request.secure=false while request.scheme=https?

I may have not been clear.

My need is the opposite : I want to have request.secure=true but
request.scheme=http.

However, if request.secure=true, whatever is the value of
request.scheme, Tomcat generates a secure JSESSIONID cookie. My
problem is that most http clients treat secure cookie as ssl only
and thus, my JSESSIONID cookie is ignored.

I face this problem with Apache Http Client for example.


  My usecase is : an application receives requests from both the
  internet and from other servers of my data center (same trusted zone).
  The requests coming from the internet may use http or https when
  internal request use http (for security and CPU consumption reasons).
  The application's web services require a secure channel (https from
  the internet or http from the trusted zone).

 What is the danger of saying that request.scheme=https in your case?

I would prefer to have request.scheme with the value that was used by
the http client in case an application uses the scheme.


Thanks for your time,

Cyrille

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Secure jsessionid cookie : request.scheme==https versus request.secure == true

2009-06-22 Thread Cyrille Le Clerc

Thanks very much for the time you spend on my problem Christopher.

I use two connectors : one with secure=true and scheme=http ; another
with secured=true, scheme=https.

 What is the requirement that scheme=http? You can actually use a
 (non-secure) HTTP connector and still set scheme=https. Do you have some
 portion of your application that relies on request.getScheme() returning
 HTTP?

My application only checks request.secure=true.

I would like Tomcat to create non-secure JSESSIONID cookies (ie
non-ssl cookies) on the connector with secure=true and scheme=http.

Today, if request.secure=true and request.scheme=http then Tomcat
creates a secure JSESSIONID cookie that is ignored by http clients
like Apache Http Client because these clients associates secure
cookies with HTTPS.

The modification would be that Tomcat to rely on request.scheme=https
to create secure JSESSIONID cookies instead of relying on
request.secure=true as it is done today. It would require one line of
change on org.apache.catalina.connector.Request:

   protected void configureSessionCookie(Cookie cookie) {
...
+ if (https.equals(getScheme())) {
- if (isSecure()) {
   cookie.setSecure(true);
   }
   }


 If HTTPS is not being used /at all/, then why do you want to claim that
 it is secure? If you aren't using SSL, then not having SSL cookies
 shouldn't be a problem, right?

My problem is to have SSL cookies for HTTP requests : if
request.scheme=http and request.secure=true, then Tomcat creates a
secure JSESSIONID cookie (ie an SSL cookie) when I would like
non-secured (ie non-secured) cookies.

  I would prefer to have request.scheme with the value that was used by
  the http client in case an application uses the scheme.

 In that case, scheme should be honestly set to the scheme being used
 by the Connector, which ought to be known in advance.

Agreed, it is what I do.

Thanks again for your time,

Cyrille

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Secure jsessionid cookie : request.scheme==https versus request.secure == true

2009-06-22 Thread Cyrille Le Clerc

Thank you for the clarification Mark.

 Depending on where the session is created, you might be able to use a
 filter to wrap your response and modify the secure attribute of any
 cookies as they are added to the response.

I am sorry to bother you but I don't see how I could wrap the class
o.a.c.connector.Response whose method addCookieInternal(cookie)  is
called by o.a.c.connector.Request.doGetSession(boolean)  to create the
JSESSIONID cookie.

As o.a.c.connector.Response is a class, I cannot use j.l.reflect.Proxy
that only supports interfaces. Do you have in mind AOP, subclassing
o.a.c.connector.Response or another approach ?

If all this is to complex, I will fall back to another approach that
is to do pattern matching (10.*) on request.remoteAddr to flag
RequestFacade.secure=true if the requests come from my secured network
area. This will let request.secure=false if request.scheme=http and
thus have non-secure JSESSIONID cookies.
I tested with a valve called SecuredRemoteAddressesValve (1) that I
precede of RemoteIpValve (2) to process the x-forwarded-for header to
find the real remoteAddr and this works fine.

Thanks very much for your help,

Cyrille


(1) 
http://xebia-france.googlecode.com/svn/tomcat/xebia-tomcat-extras/tags/xebia-tomcat-extras-0.5/src/main/java/org/apache/catalina/connector/SecuredRemoteAddressesValve.java
(2) 
http://xebia-france.googlecode.com/svn/tomcat/xebia-tomcat-extras/tags/xebia-tomcat-extras-0.5/src/main/java/org/apache/catalina/connector/RemoteIpValve.java


On Tue, Jun 23, 2009 at 12:40 AM, Mark Thomasma...@apache.org wrote:
 Cyrille Le Clerc wrote:
 Thanks very much for the time you spend on my problem Christopher.

 I use two connectors : one with secure=true and scheme=http ; another
 with secured=true, scheme=https.

 What is the requirement that scheme=http? You can actually use a
 (non-secure) HTTP connector and still set scheme=https. Do you have some
 portion of your application that relies on request.getScheme() returning
 HTTP?

 My application only checks request.secure=true.

 I would like Tomcat to create non-secure JSESSIONID cookies (ie
 non-ssl cookies) on the connector with secure=true and scheme=http.

 Today, if request.secure=true and request.scheme=http then Tomcat
 creates a secure JSESSIONID cookie that is ignored by http clients
 like Apache Http Client because these clients associates secure
 cookies with HTTPS.

 The modification would be that Tomcat to rely on request.scheme=https
 to create secure JSESSIONID cookies instead of relying on
 request.secure=true as it is done today. It would require one line of
 change on org.apache.catalina.connector.Request:

    protected void configureSessionCookie(Cookie cookie) {
 ...
 +         if (https.equals(getScheme())) {
 -         if (isSecure()) {
            cookie.setSecure(true);
        }
    }


 If HTTPS is not being used /at all/, then why do you want to claim that
 it is secure? If you aren't using SSL, then not having SSL cookies
 shouldn't be a problem, right?

 My problem is to have SSL cookies for HTTP requests : if
 request.scheme=http and request.secure=true, then Tomcat creates a
 secure JSESSIONID cookie (ie an SSL cookie) when I would like
 non-secured (ie non-secured) cookies.

 The Tomcat code will not be changed to behave in this way.

 The secure attribute is intended for use in architectures like:

 client --https-- httpd --http/ajp-- tomcat

 Depending on where the session is created, you might be able to use a
 filter to wrap your response and modify the secure attribute of any
 cookies as they are added to the response.

 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

Secure jsessionid cookie : request.scheme==https versus request.secure == true

2009-06-21 Thread Cyrille Le Clerc

   Hello,

   I am interested in using the secure attribute of Tomcat
connectors for non https/ssl requests. However, the ssl only
JSESSIONID cookie mechanism currently relies on request.secure ==
true rather than on request.scheme == https (1). A confusion on
secure vs. https seems to come from the fact that cookie.secure ==
true is interpreted by most http clients as cookie.sslOnly == true.
   Due to this behavior, I don't see how I can use connector.secure =
true without connector.scheme = https.

   Could we imagine an evolution of Tomcat to generate secure session
cookies if request.scheme == https rather than on request.secure ==
true ? I would be very pleased to propose a patch.

   My usecase is : an application receives requests from both the
internet and from other servers of my data center (same trusted zone).
The requests coming from the internet may use http or https when
internal request use http (for security and CPU consumption reasons).
The application's web services require a secure channel (https from
the internet or http from the trusted zone).
   If Tomcat handled secure session cookies on request.scheme ==
https rather than request.secure == true, I would handle this with
three connectors thanks to the nuance between the secure and
scheme attributes of the connectors :
- external over http connector : secure = false, scheme = http
- external over https/ssl connector : secure = true, scheme = https
- internal over http connector : secure = true, scheme = http
   Today, I handle this in the application wrapping the Http Servlet
Request to declare secure requests whose remoteAddr matches the 10.*
block.

   Cyrille

(1) See 
http://fisheye6.atlassian.com/browse/tomcat/trunk/java/org/apache/catalina/connector/Request.java?r=HEAD#l2367
(2) web browsers, Apache Commons Http client, etc

--
Cyrille Le Clerc
cyrille.lecl...@pobox.com clecl...@xebia.fr
http://blog.xebia.fr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

37 matches

Mail list logo