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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
