On Mon, 24 Mar 2003, Aditya wrote:
> Date: Mon, 24 Mar 2003 13:34:57 -0800 > From: Aditya <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Developers List <[EMAIL PROTECTED]> > Subject: Re: domain-wide session cookies? > > > On Mon, 24 Mar 2003 11:44:04 -0800 (PST), "Craig R. McClanahan" <[EMAIL > > PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
