Hi.
A couple of emails ago, I think you showed the code that was doing a
redirect, and said that that was where it seemed to be "losing the cookie".
Let me get back to a couple of my oen emails ago, just to set matters
straight : a cookie is "a browser thing". If the browser has never seen
the cookie, it can never send it back on a subsequent request, right ?
I wonder if the re-direct you are doing, from the HTTPS to the HTTP
server, would not by any chance be some kind of purely internal
redirect, without going to the browser at all.
So that the HTTPS part "thinks" it is setting a cookie, but in fact the
browser never gets that response, so the browser never gets the cookie.
That may be hidden somewhere in the code that is being called to do the
redirect, and which under earlier versions may have done an external
redirect (with a back-and-forth through the browser), but which now has
become purely internal.
A lot of speculation here, but who knows ?
Now, I know I am being a pain, but you have a puzzling problem, and
sometimes it is the obvious things that one does not see.
So let me again insist : a cookie is a browser thing.
If you open your browser and navigate to a server, and at some point
this server sends back a response with a cookie, the browser will
*always* send back that cookie on any subsequent request to the same
server, unless :
- the browser is set to ignore cookies
- it never received the cookie in the first place
- the user manually (or programmatically) deletes the cookie from the
browser cookie store.
- you close the browser, and the cookie was "for the session only".
The next time you open the browser, the cookie is gone then.
- the cookie expires (expiration date/time is past)
- the cookie has been re-sent in the meantime by the server, with a
date/time such that it has expired (that's the same as the previous
case, except that here it is the server that decided at some point to
"expire" the cookie, by updating it)
- the cookie is marked "secure" (HTTPS-only), and you are not (or no
longer) on an HTTPS connection.
To my knowledge, there exists no case where the browser would not send a
cookie with every request, if it has it and it is valid.
(So for instance, make sure that the code which is setting the cookie,
has not changed so that now it is still setting a cookie, but one that
is immediately expired.)
And one more :
When a server sends a cookie to a browser, it happens by means of a HTTP
header in a response to the browser. This HTTP header is
"Set-Cookie:(cookie value)"
When a browser sends a cookie to a server, it happens by means of a HTTP
header joined to a request. The header then is
"Cookie: (cookie-value)".
So, if by some circumstance that I cannot really fathom, the server
would compose a response with a cookie, it would do it by adding a HTTP
header "Set-Cookie". If that response would be short-circuited and go
back right into the server, the input side of the server would not see
this cookie, because it does not arrive in a "Cookie" header.
André
krusek wrote:
We use tomcat forms authentication and it is cookies being used.
There are 3 cookies, JSESSONIDSSO, test and JSESSONID.
Not sure how you tell if its marked secure? The test cookie is for testing
to assure cookies are enabled.
Thanks for your help!
Rainer Jung-3 wrote:
krusek wrote:
I have Apache 2 with SSL, mod_jk connection, and Tomcat. Everything has
worked peachy from one tomcat upgrade after another. However now I
upgraded
to tomcat 6 and I am loosing the session when switching from https to
http
within the same domain.
For clarity, Apache 2 is handling SSL not tomcat.
Does anyone know why this is happening?
Are you using cookies for the sessions (JSESSIONID cookie) or URL
encoding (";jsessionid=")?
Is some cookie flagged as being "secure"?
You can check how the cookie looks like e.g. using Firefox (Preferences
- Privacy - Cookies).
Thanks!
Kevin
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
