Hmm, the popup is this case is definitely accessing a different domain. We have our main site www.foo.com and a secure site for transactions (secure.foo.com). We actually don't care about sessions on the popup secure site because it uses it's own session. The problem appears to be that once the popup has been fired, the main (www.oursite.com.au) site "looses" it's session. We are also having problems with people who run two browsers on two of our sites. This also causes session lose. Although I am inclined to think that the real problem is the browsers over writing each others cookies.
My real problem is that I have not been able to find much doco which discusses session tracking on multiple sites and multiple browsers. So if you know any please link me to it ;-) I have gotten around most of this by setting the cookies domain to be ".foo.com" with a path of "/", but ideally I would like to not have to do this and let Tomcat do it's thing so that we don't have to have cookies enabled. If it was me, I would never have designed it this way, but the system was built by someone else ;-) Ciao D -----Original Message----- From: Mike Curwen [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 March 2004 4:18 AM To: 'Tomcat Users List' Subject: RE: Loosing sessions when poping a window We had a cookie problem here at work, and it was all the same domain, and we couldn't figure it out.. until we recognized that foo.com and www.foo.com were two *different* domains, and therefore the browser would treat them differently. So we have apache set up like so: virtual host name: foo.com alias www.foo.com Someone accesses foo.com they're redirected (internally) to login.jsp (under foo.com) then they put in their user/pass and their session is prepopulated. Then they are issued a sendRedirect to 'www.foo.com'. An apparently authenticated user accesses www.foo.com they're redirected (internally) to login.jsp (under www.foo.com) the second authentication then "succeeds". In fact they both did, but to the end user it looks like they have to login twice. And of course, it works fine if you just came in through www.foo.com Is the popup perhaps accessing something like this? (looks like the same domain but isn't)? As for this: > This may be part of the problem > as my research indicates that tomcat regard path changes as being > context changes and therefore issues a new session. Does the popup load something from a completely different webapp context? If this is the case, then the jsessionid wouldn't work, because it's tied to the first context. It's not just a 'simple' path change, like on a web server. It's a whole new app. > -----Original Message----- > From: Derek Clarkson [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 04, 2004 5:25 PM > To: 'Tomcat Users List' > Subject: RE: Loosing sessions when poping a window > > > Yes, here is my reply to the postings you linked to: > > Hello everyone, I just found this posting. I have had the same > problem. Opening a window causes the session to change. > BIG NOTE: I have reproduced this in FireFox - therefore it is NOT IE > specific. > > I solved it by writing a cookie for JSESSIONID explicitly setting the > domain to our domain and the path to the root path "/". It seems these > two parameters are required to solve this. > > Interestingly enough, when I monitored the cookies being used through > out the program, I would regularly see two cookies called JSESSIONID. > One my custom built cookie and the other being Tomcats session > tracking one. What interesting is that despite setting the domain and > path, both cookies returned nulls in these fields. > > I'm still trying to figure out how Tomcat sees a new window as a new > session, although within my app, we are also loading a jsp from a > different path. This may be part of the problem as my research > indicates that tomcat regard path changes as being context changes and > therefore issues a new session. > > Hope this helps. > Derek. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
