-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 9/14/2010 12:30 PM, Mark Thomas wrote:
> On 14/09/2010 15:16, Christopher Schultz wrote:
>
> I'm in the middle of some major re-factoring so I don;t have time to
> actually test this...
>
>> 0. [Browser has two JSESSIONID cookies: one secure=true and one
>> secure=false]
>
> This I doubt. When testing load-balancing on a single machine, I have
> seen browsers send the same cookie to two Tomcat instances that only
> differ by port number. I suspect https and http will be treated the same
> way and one cookie will just overwrite the other. You should test that
> to be sure though.
Okay, I'll check. I believe that "version 0" cookies should overwrite
each other when the port numbers are different, but that "version 1"
cookies allow a port specification that should allow two cookies with
the same name and path, but different numbers, to exist side-by-side
with no interference.
I just checked, and RFC 2109 ("version 0" cookies) does seem to indicate
that the port number adds to the unique-ness of the hostname, therefore
my statement above appears to be incorrect. It's possible that web
browser were (at some point) lazy and I am remembering a bad cookie
implementation.
The Set-Cookie2 definitely has a "port" parameter that can be explicitly
added to the cookie's settings.
Regarding the "Secure" flag, this is all the RFC has to say about it:
"
Secure If absent, the user agent MAY send the cookie over an
insecure channel.
"
That indicates to me that non-secure cookies should be sent as well as
secure cookies, but doesn't say if they overwrite each other. I didn't
read every word of the RFC, but from what I did read, this appears to be
a gray area where the browser would be left to either support separate
secure/non-secure cookies or clobber one with the other.
References
http://www.ietf.org/rfc/rfc2109.txt
and
http://www.ietf.org/rfc/rfc2965.txt
(This information was mostly for the edification of other readers, not a
lesson in HTTP RFCs for markt ;)
Here's what I observe in Tomcat 6.0.26 with Mozilla Firefox 3.6.9/win32:
[non-secure]
1. Attempt to access protected page, request includes JSESSIONID cookie
(old value, no valid session)
2. Server responds with 302 redirect to login page, Set-Cookie for
JSESSIONID, path=/mywebapp
3. Submit authentication information, including JSESSIONID from step 2
4. Server accepts credentials, issues 302 response, no Set-Cookie header
5. Client follows redirect, including JSESSIONID from step 2
[secure, immediately after steps 1-5 above]
6. Attempt to access protected page, request includes JSESSIONID from step 2
7. Access is granted, page is displayed
8. Request "logout", request includes JSESSIONID from step 2
9. Server terminates HttpSession, no Set-Cookie header in response
10. Attempt to access protected page, request includes JSESSIONID from
step 2
11. Session is invalid, server responds with 302 redirect to login page,
Set-Cookie header with new JSESSIONID cookie value AND SECURE FLAG SET
12. Client follows redirect, includes JSESSIONID from step 11
13. Submit authentication information, including JSESSIONID from step 11
14. Server accepts credentials, issues 302 response, no Set-Cookie header
15. Client follow redirect, including JSESSIONID from step 11
[non-secure, immediately after steps 6-15 above]
16. Attempt to access protected resource, request does not include
JSESSIONID cookie at all
17. Server responds with 302 redirect to login page, Set-Cookie for
JSESSIONID, path=/mywebapp
18. Submit authentication information, includes JSESSIONID FROM step 17
19. Server accepts credentials, issues 302 redirect
20. Client follows redirect, including JSESSIONID from step 17
[secure, immediately after steps 6-15 above]
21. Attempt to access protected resource, request includes JSESSIONID
cookie from step 17
So, it appears that the non-secure cookie trumps the secure cookie and
the client (Firefox, at least) will clobber secure with non-secure.
I encourage others to test other browsers. This was exhausting. :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyP4QcACgkQ9CaO5/Lv0PBS3wCeLHzEbJew0T2/I/VFTonga84m
5VQAoJx4RQhmPDmr74E79ocGvnJPVZ2N
=aOIa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
