tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Moving from a very old Tomcat to a new Tomcat.
Date Wed, 11 Jun 2008 09:04:39 GMT
This has been a long thread, and somewhere along the line I must have 
gotten lost.
There are two areas that puzzle me, and I would be grateful if someone 
could enlighten me for future reference.
Feel free to blast me away if I ask any stupid questions below.
I am neither a Java nor a Tomcat specialist, I just dabble in 
applications under Apache and Tomcat, and my purpose is only to make 
sure I do understand what is going on.
Also feel free to point me to the authoritative documentation if any.

 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
- 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.
- 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.

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 misss a post somewhere ?

- how exactly does one "override" the Tomcat-generated JSESSIONID 
cookie?  Just by overwriting it after Tomcat created it anyway ?
(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 ?)

This last question rests on my lack of knowledge regarding  when Tomcat 
exactly decides to generate this JSESSIONID cookie.
I kind of imagine that at each request, Tomcat checks if there is 
already a JSESSIONID cookie with the request.
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.
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 ?

And this basically is a different topic from any authentication that may 
or may not (also) take place during the first interaction.
(I mean that the JSESSIONID cookie will be created whether or not 
authentication takes place).
Still ok ?

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 ?


Thanks
André



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message