-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
André Warnier wrote:
| From the thread (or two threads), I gather that :
| - originally, the problem was stated as "losing the cookie/session",
| after moving to a more recent Tomcat version, without any other
| changes
Yes, but the OP didn't say whether no changes were made to the original
code (or configuration) when moving between Tomcat versions.
| - then it gradually filtered out that the problem was due to the fact
| that the session-cookie JSESSIONID, due to being originally created in
| an HTTPS part of the interaction, was created (by Tomcat) as a "secure"
| cookie. Therefore, when switching back to an HTTP part of the
| interaction, the browser stops sending ditto cookie, and at the server
| side this causes an inability to reconnect to the existing session, thus
| for all intents and purposes a practical loss of the session.
Correct (and this behavior /is/ what Tomcat exhibits).
| - and finally the working solution was found by making the "login
| servlet" create the JSESSIONID cookie itself, "instead of letting Tomcat
| do it", and in the process seeing to it that ditto cookie is not marked
| as "secure". This in turn changes the situation so that now the browaer
| is still sending the cookie for the non-HTTPS part of the interaction,
| and everything is fine again.
Correct.
| What I am still confused about is :
|
| - the behaviour of browsers versus secure/non-secure cookies is not new,
| and neither is the fact that Tomcat generates a secure JSESSIONID cookie
| when the session starts under HTTPS. So how come this thing was working
| before the Tomcat change of version, but no longer afterward ?
| Or did I miss a post somewhere ?
It's tough to tell. The OP was using TC 3.2.4 (ancient!) and it might
not have been setting the "secure" flag on that cookie. It's the
cookie's "secure" flag that dictates the security policy, not the use of
HTTPS (or not). You could go back and look at the code for 3.2.4 and see
if the "secure" flag was being set on cookies.
| - how exactly does one "override" the Tomcat-generated JSESSIONID
| cookie? Just by overwriting it after Tomcat created it anyway ?
Yes.
| (And, as a secondary question, what does one exactly put in it then, so
| that it still matches the "session key" ? Or can you just put something
| arbitrary in it, and Tomcat will use whatever is there to identify the
| session data store ?)
The cookie must be called JSESSIONID, and the value must be the id of
the session. So, you can just do something like this:
response.addCookie(new Cookie("JSESSIONID",
~ request.getSession().getId());
Technically, this creates an additional cookie with the same name, and
I'm not sure how Tomcat (or the browser) handles this. You could use
LiveHTTPHeaders or an equivalent to see what is sent by the server, and
then from the browser.
| This last question rests on my lack of knowledge regarding when Tomcat
| exactly decides to generate this JSESSIONID cookie.
Tomcat generates the cookie the first time you call
HttpServletRequest.getSession(true) and the session is actually created.
| I kind of imagine that at each request, Tomcat checks if there is
| already a JSESSIONID cookie with the request.
It's not guaranteed to check until you call either
HttpServletRequest.getSession or
HttpServletRequest.isRequestedSessionIdValid. If I were implementing a
servlet container, I'd locate the session only when necessary.
| If there is, Tomcat basically leaves it alone, allowing some application
| afterward to use its value to reconnect to an existing session
| identified by the value contained in the cookie.
Well, since TC manages the sessions for the application, the application
doesn't really do any "reconnection" of its own.
| If there isn't a JSESSIONID cookie, then Tomcat assumes this is a new
| session and, by its own decision, generates a new "session data store",
| and a new cookie to go with it.
| Is that understanding correct ?
Yes.
| And this basically is a different topic from any authentication that may
| or may not (also) take place during the first interaction.
Correct. Authentication is not relevant to the session discussion
(except that many people use sessions to tract authentication).
| (I mean that the JSESSIONID cookie will be created whether or not
| authentication takes place).
| Still ok ?
Yup.
| But, there may be a chronological sequence in the above : in case the
| first interaction results in authentication, does Tomcat generate the
| JSESSIONID cookie and session data before, or after the authentication
| takes place ? Or is this the wrong way of asking the question ?
If no session exists, and Tomcat is managing the authentication, then a
cookie is created and sent back to the client, who then authenticates
with the server by sending the credentials /and/ the (somewhat newly
created) session cookie. Thus, the authentication occurs within the
context of a pre-existing session.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhP1RYACgkQ9CaO5/Lv0PBCWwCeIe5aB+XPhm/1xBVu1a0s3tlL
VQkAnRBryeZc847slt8Mkz+c8GkrY9nc
=GdRk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
