tomcat-dev mailing list archives

On Mon, 24 Mar 2003, Aditya wrote:
> Date: Mon, 24 Mar 2003 13:34:57 -0800
> From: Aditya <aditya@grot.org>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> Subject: Re: domain-wide session cookies?
>
> > On Mon, 24 Mar 2003 11:44:04 -0800 (PST), "Craig R. McClanahan" <craigmcc@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.
>
Consider that the initial access to your shared app was on virtual host A.
If all of the other accesses to that app, for a particular session, also
used virtual host A in their URLs, you wouldn't have a problem, right?
The session cookie would include virtual host A as the "domain", so the
cookie would always be returned on those subsequent requests. (The
simplest way to accomplish this would be to always use relative URLs for
intra-application hyperlinks).
Sharing a session across virtual hosts violates the Servlet spec (Section
7.3 - "HttpSession objects must be scoped at the application (or servlet
context) level" and Section 3.6 - "Servlet contexts can not be shared
across virtual hosts"), so you should not really be surprised to find the
logic for setting up a session cookie be hard coded in the manner you
describe.
> Thanks,
> Adi
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org