> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 2:55 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 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?
Direct to back-end processing in the app (as far as I know).
>
> > 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.)
>
That actually makes sense.
> 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?
So far, it looks like it is maintaining an X=Y philosophy.
So that's a non-starter.
>
> > 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?
>
Yes, and the problem only rears its ugly head on a successful login (app
expires old cookie, creates a new one).
User never even sees a new page, just an app-generated "session expired" error.
Trying to see things in access logs, but nothing there I can see.
> >>>> 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.
Not fronting with HTTPD, so above isn't helpful.
Thinking a new ROOT with just an index.html that redirects to /APP1 or using
something like Tuckey for it.
>
> - -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
