> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Friday, September 04, 2015 12:46 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Multiple JSESSIONID cookies being presented. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jeffrey, > > On 9/4/15 12:37 PM, Jeffrey Janner wrote: > > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm > > also seeing this on Windows (version doesn't matter), with Tomcat > > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51. > > > > I have 2 contexts installed in Tomcat, one is ROOT, the other > > APP2. Both contexts start off at a login screen unique to the > > context and provided by it (not using container auth). > > > > When I connect to ROOT, no problem, but when I connect to APP2, I > > get 2 JSESSIONID cookies, one with the path "/" and the other with > > the path "/APP2/". > > I would expect this behavior: you have one ROOT app (cookie path=/) > and one APP2 app (cookie path=/APP2). Your browser will send both > cookies to /APP2 because / is a prefix of /APP2. > > > On the Windows implementations, we are not seeing a problem, at > > least not one being reported. > > > > On the Linux implementation, the end user will occasionally get > > immediately kicked out with an invalid session immediately after > > providing credentials. The access logs show a single > > jsessionid=xxx being provided on the POST URL. > > The POST to j_security_check? > No
> Are you using request.encodeURL() to build the <form> action URL, or > are you building it manually? > EncodeUrl. And a check of a couple of sites, both linux and windows, shows that the jsessionid is being added to the action by EncodeUrl, regardless of cookie settings. So far, it is always the APP2 sessionID. > I believe Tomcat prefers the Cookie-based session id to anything > coming-in from the URL, and I do know it will search all JSESSIONID > cookies for any that match a valid session (not just the first one) in > the current application. So logging-in should ... always work. > > > Amazingly, sometimes that goes through and lets the user login, so > > my theory is that the browser is sometimes picking the wrong path. > > (Also, theory, the "/" cookie is being generated by a request for > > "/favicon.ico" just before the request for the login page.) > > You should make sure that anything that doesn't require authentication > specifically mentions that in web.xml, otherwise you'll get weird > things happening like that. > We don't actually use Tomcat container authentication at all. > > So my question is: Is there anything I can do from a > > configuration perspective to get it to NOT send the "/" cookie for > > APP2? > > Not really... other than changing from ROOT to APP1 or whatever. > Overlapping URL spaces for applications leads to tears. > I could do that, though we'd like to keep it so that if no context is specified we still go to APP1, so the user's don't have to change all of their bookmarks. Perhaps with a redirect? > > Deployment details: > > I think there's nothing in here that would change anything. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJV6di6AAoJEBzwKT+lPKRY77QQAKzjMEDTVHYzqeFfhS9F9XUO > qrIwlcXlxolclLO2CYaBNoYgcPm1CM8UPMc88s3ysmjLU37dohR8rd1Ukkyp9hdG > 0hRV7siKip3t2sj/EDBmslJOKyShlURAqLne14MkQaVvYz/i985MUDrRnlx9zujf > VjR5T0SV+M20ZOXoMN8S1ME09GMJktRajSs5T8rllwvMg+YtdmTo+hWfuerJNrj0 > yRBVFkAVs1UOH64RvHud+M3lYleb2UrrE/ZxofDihBcmipKWNEV6W/fu/7uEQVLc > Hysc6CDh90L7xmoV8ndR6QoqNr4gX04mghRaU+PZiB6uPuPgYpJDaJ1wDITOrFnf > BVkXYRh1KICMzSyW1T2K8ZU+NkG4dp0RVI++IzjOuDy+i/EJ9opnNyRols8NkC0w > QLOueV6EbWZFbo9tZxJmaRS7Y7RObcbg/uk5JE9trK4KGcB/MtJQXWhk4Su5ZokS > 5+knrgBbWbPcgH5x/1ten/BGkndp28C85FDci0AgsAFCbmim7KuuSL1oRRtLM5kw > WNOeWpJzOQ3FAHV6TqPWLiAclo9/1gTMJZKQtxH+sW5OWYEa/9Ch2ZCArewy5Z+m > KaNMfnXBrXlL9MGYyIQKiFVRUCyn/cyKKAlj9nLVbIBIsHeslCE7zq8zE15EOHVn > 7v5mbzif9Ira1ZGLFBjC > =5N0l > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
