Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 48005 invoked from network); 24 Mar 2003 22:11:09 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 24 Mar 2003 22:11:09 -0000 Received: (qmail 14744 invoked by uid 97); 24 Mar 2003 22:13:00 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@nagoya.betaversion.org Received: (qmail 14737 invoked from network); 24 Mar 2003 22:12:59 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 24 Mar 2003 22:12:59 -0000 Received: (qmail 47174 invoked by uid 500); 24 Mar 2003 22:11:00 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 47163 invoked from network); 24 Mar 2003 22:11:00 -0000 Received: from icarus.apache.org (208.185.179.13) by daedalus.apache.org with SMTP; 24 Mar 2003 22:11:00 -0000 Received: (qmail 13499 invoked by uid 1059); 24 Mar 2003 22:10:59 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 24 Mar 2003 22:10:59 -0000 Date: Mon, 24 Mar 2003 14:10:59 -0800 (PST) From: "Craig R. McClanahan" To: Tomcat Developers List Subject: Re: domain-wide session cookies? In-Reply-To: Message-ID: <20030324140424.W83436@icarus.apache.org> References: <20030321054020.GA13094@mighty.grot.org> <20030324114236.C42988@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 24 Mar 2003, Aditya wrote: > Date: Mon, 24 Mar 2003 13:34:57 -0800 > From: Aditya > Reply-To: Tomcat Developers List > To: Tomcat Developers List > Subject: Re: domain-wide session cookies? > > > On Mon, 24 Mar 2003 11:44:04 -0800 (PST), "Craig R. McClanahan" 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