[ACCEPTED]-Best way for allowing subdomain session cookies using Tomcat-subdomain

This is apparently supported via a configuration 2 setting in 6.0.27 and onwards:

Configuration 1 is done by editing META-INF/context.xml

<Context sessionCookiePath="/something" sessionCookieDomain=".domain.tld" />

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

I have just gone through all of this looking 53 for a simple solution. I started looking 52 at it from the tomcat perspective first.

Tomcat 51 does not give direct access to configuring 50 the domain cookie for the session, and I 49 definitely did not want to custom patch 48 tomcat to fix that problem as shown in some 47 other posts.

Valves in tomcat also seems 46 to be a problem solution due to the limitations 45 on accessing headers & cookies built 44 into the Servlet specification. They also 43 fail completely if the http response is 42 commited before it gets passed to your valve.

Since 41 we proxy our requests through Apache, I 40 then moved onto how to use apache to fix 39 the problem instead.

I first tried the mod_proxy 38 directive ProxyPassReverseCookieDomain, but 37 it does not work for JSESSIONID cookies 36 because tomcat does not set the domain attribute 35 and ProxyPassReverseCookieDomain cannot 34 work without some sort of domain being part 33 of the cookie.

I also came across a hack 32 using ProxyPassReverseCookiePath where they 31 were rewriting the path to add a domain 30 attribute to the cookie, but that felt way 29 to messy for a production site.

I finally 28 got it to work by rewriting the response 27 headers using the mod_headers module in 26 apache as mentioned by Dave above.

I have 25 added the following line inside the virtual 24 host definition:

Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5"

The above should all be 23 a single line in the config. It will replace 22 any JSESSIONID cookies domain attribute 21 with ".example.com". If a JSESSIONID cookie 20 does not contain a domain attribute, then 19 the pattern will add one with a value of 18 ".example.com". As a bonus, this solution 17 does not suffer from the double JSESSION 16 cookies problem of the valves.

The pattern 15 should work with multiple cookies in the 14 Set-Cookie header without affecting the 13 other cookies in the header. It should also 12 be modifiable to work with other cookies 11 by changing JSESSIONID in the first part 10 of the pattern to what ever cookie name 9 you desire.

I am not reg-ex power user, so 8 I am sure there are a couple of optimisations 7 that could be made to the pattern, but it 6 seems to be working for us so far.

I will 5 update this post if I find any bugs with 4 the pattern. Hopefully this will stop a 3 few of you from having to go through the 2 last couple of days worth of frustrations 1 as I did.

As a session (and its Id) is basically considered 28 of value only for the issueing application, you 27 may rather look for setting an additional 26 cookie. Have a look at Tomcats SingleSignOnValve, providing 25 the extra-Cookie JSESSIONIDSSO (note the 24 ...SSO) for the server path "/" instead 23 of "/applicationName" (as JSESSIONID cookies 22 are usually set).

With such a Valve you may 21 implement any interprocess communication 20 you need in order to synchronize any state 19 between different servers, virtual hosts 18 or webapps on any number of tomcats/webservers/whatever.

Another 17 reason why you cannot use tomcats session 16 cookie for your own purposes is, that multiple 15 webapps on the same host have different 14 session ids. E.g. there are different cookies 13 for "/webapp1" and "/webapp2". If you provide 12 "/webapp1"'s cookie to "/webapp2", this 11 wouldn't find the session you referenced, invalidate 10 your session+cookie and set its own new 9 one. You'd have to rewrite all of tomcats 8 session handling to accept external session 7 id values (bad idea securitywise) or to 6 share a certain state among applications.

Session 5 handling should be considered the containers 4 (tomcats) business. Whatever else you need 3 you should add without interfering with 2 what the container believes is necessary 1 to do.

I've run into this at $DAYJOB. In my case 12 I wanted to implement SSL signon then redirect 11 to a non SSL page. The core problem in tomcat 10 is the method (from memory) SessionManager.configureSessionCookie 9 which hard codes all the variables you would 8 like to get access to.

I came up with a 7 few ideas, including a particularly egregious 6 hack using mod_headers in apache to rewrite 5 the cookie based on regex substitution.

The 4 definative way to solve this would be to 3 submit a patch to the tomcat developers 2 that adds configurable parameters to the 1 SessionManager class.

The valve techniques do not seem to be 100% perfect. If 6 you dare to modify Tomcat itself:

catalina.jar contains 5 the following class: org.apache.catalina.connector.Request

The Request has a method:

configureSessionCookie(Cookie cookie)

For 4 our environment it was best to just hardcode 3 it, but you could do more fancy logic:

cookie.setDomain(".xyz.com");

Seems 2 to work perfectly. Would be nice if this 1 was configurable in tomcat.