8 messages in org.apache.tomcat.devRe: domain-wide session cookies?| From | Sent On | Attachments |
|---|---|---|
| Aditya | Mar 20, 2003 9:39 pm | |
| Aditya | Mar 21, 2003 2:50 pm | |
| Craig R. McClanahan | Mar 24, 2003 11:43 am | |
| Aditya | Mar 24, 2003 1:34 pm | |
| Craig R. McClanahan | Mar 24, 2003 2:10 pm | |
| Aditya | Mar 24, 2003 5:07 pm | |
| Craig R. McClanahan | Mar 24, 2003 9:31 pm | |
| Aditya | Mar 24, 2003 10:55 pm |
| Subject: | Re: domain-wide session cookies? | |
|---|---|---|
| From: | Aditya (adi...@grot.org) | |
| Date: | Mar 24, 2003 1:34:35 pm | |
| List: | org.apache.tomcat.dev | |
On Mon, 24 Mar 2003 11:44:04 -0800 (PST), "Craig R. McClanahan"
<crai...@apache.org> said:
Under Tomcat-4 it looks like the session cookie is set in:
org/apache/catalina/connector/HttpResponseBase.java
and the code that sets it uses the default domain (which is equal to
the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. ".domain.tld" however it seems silly to hardcode it in the above class.
Before I tackle this:
0) is there a better way to do it?
1) if not, is this the right place to do it?
2) what is the best place (ie. where in server.xml) to put an option
to enable this?
I personally prefer option 3 -- don't change anything. Exposing session id cookies to a broader audience than just the webapp that created them is a security vulnerability. If you need to share stuff across webapps, use some other cookie, not the container-managed one.
It's a little more "wierd" and esoteric than that -- we have multiple virtual hosts (all in the same second-level domain) pointing at a single webapp/context (with Apache/mod_jk) and we need to have sessions shared across the virtual hosts.
I started by reimplementing a parallel session manager that wrote a domain cookie, but that seemed silly, so I've written a filter that writes a copy of the session cookie valid for the entire domain when the session.isNew(). Of course, this isn't perfect since Tomcat insists on writing the default host session cookie *after* all filters are evaluated...which might be construed as a bug/feature. After all, shouldn't filters have the ability to manipulate the entire HTTP response?
If anyone has a suggestion on how to deal with that, I would welcome any hints.
Thanks, Adi