-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeffrey,
On 9/4/15 3:31 PM, Jeffrey Janner wrote: >> -----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. >> > 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 So... where does the POST go? > 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'm not surprised that the session id is being added to the URL regardless of cookie settings, because at that point, Tomcat might not know for sure if the client can support cookies. (I'm sure there are cases where it's obvious that cookies are in fact supported, but Tomcat is not detecting it.) I'm surprised that Tomcat would use the "wrong" session id for URL-rewriting when presenting the login screen. Are you saying that, when showing the login page for /APP2, Tomcat will: a. Place a session identifier in the URL with value X b. Return a Set-Cookie response header for JSESSIONID with value Y Where X != Y? > 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. Okay, that's good information to have. But you do use Tomcat's session-tracking mechanisms, right? >>>> 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? That kind of thing is tough to do, but possible. Something like this: # Ignore requests to /APP1 RewriteCond %{REQUEST_URI} ^/APP1 RewriteRule .* - [L] # Ignore requests to /APP2 RewriteCond %{REQUEST_URI} ^/APP2 RewriteRule .* - [L] # Re-write other requests RewriteRule (.*) /APP1\1 [R,L] Be very careful with the above: it's completely untested and can put your clients into a redirect loop if you aren't careful and test all cases. Also, the [R] flag will do odd things with POST requests, so either make sure nobody POSTs to one of those URLs or expand the configuration to properly-handle POSTs. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV6fcrAAoJEBzwKT+lPKRY38QP/26NhBIE6C9QodiEfzrWpH2O 7oPAIvCNjBb2uDD/gZI6QEMR7es0FHfk/8N0/DsS6PJTO8UIOQP4QBrorviUxBQv Xowwv2rBIfARfYXYUdTAzZemnqYLDAV7eTZVYvnGvXvIpb5C7hInq3TTmMC7KKwh swB2TauBNiLbHRI2TITq51+1c6CBJAp8/sCAA4i/TBkUPJFxareuyhmKNOJKhikK bmQcbe30jkz/G9uRaft1byS/JCJot84qiuDBuW/N2y3xMZDOW/nvKUyzhaC+YrC+ SzdakkdTQTJRsVnzEhRSb9nz4fV4XdLyeCDrRhFUrVxUOHcq0p/D38Lqy75SnDRT ip31AEgdmvWy2/aTVu3LtDsYX9nQzo0s070CctZPesTGtO1u31owF6Gp6stmb1Dy dh2eaFb1mdWlZo4R/8jd+zgmdC3GQXCrup816BqdXqKHlrtXBqSo1OW/1dS/W2Vp Ldw89FPsa6tVg47t8bO1We2I/kukjqgqVH49CZqRZsaPOER7ycprWTa0ykTaeOxJ VpQFjsx3U3+/4RRFp7z9daTMjILrH6eFI9qJWM2LvS1DhpNkiS5+eWX1q1sm5WY9 McbfZXb1L3BcLVx8bp0KhsYLc+Yhkbfp/M84mSVVfrlfLMCRNz/ORQa+SYlYlz0x wcoVjKS0Ir73it0lLVSK =pTX5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
