Yep, I realized as much and went exactly that route. However, i still think that altering (broadening) domain of JSESSIONID cookie is worthwhile. However, after looking at Tomcat src, it appears that creating a delegate for the internal Request is surprisingly non-trivial as there are protected fields in that class. And wrapping a delegate around ServletResponse is useless, because JSESSIONID cookie is added using an internal method (and not HttpServletResponse.addCookie). oh well...
-nikita On Thu, Jul 1, 2010 at 5:59 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nikita, > > On 7/1/2010 6:37 PM, Nikita Tovstoles wrote: > > I borrowed "sub-domain" from Google Analytics terminology. I have one > > server, running one tomcat instance with one virtual host. That host is > > running one app - a JS/html widget that is embedded on multiple sites. > > > > We need to track usage per-deployment (per site embedding the wiget). For > > (google) analytics purposes, the easiest way to do so is to have a > different > > (sub)domain per deployment. So the same tomcat instance is responding to > > requests for site1.widget.com, site2.widget.com, etc. > > > > a user may interact with 2 widget deployed on 2 different sites (and thus > > served from different (sub)domains) within 30 minutes. It is for this > case > > that we want user to share the same HttpSession: > > > > - go to some site A where our widget is deployed at site1.widget.com > > - go to some other site B where our widget is deployed at > site2.widget.com > > - reuse the same JSESSIONID because its' domain is set to ".widget.com" > > This sounds like a job for a non-JSESSIONID cookie that is created from > your own code. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwtOg0ACgkQ9CaO5/Lv0PDlagCfTBxbqDKGE4bmQZG3R2ScYnsC > oN8Aniy2zW1cIhEab+18E7DvqPC3UsnF > =N0Qc > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
