-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Konstantin,
On 6/18/14, 12:05 PM, Konstantin Preißer wrote: >> -----Original Message----- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Wednesday, June 18, >> 2014 4:23 PM To: Tomcat Users List Subject: Re: Regarding >> JSESSIONIDSSO Cookie maintained by tomcat >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Konstantin, >> >> On 6/18/14, 5:34 AM, Konstantin Kolinko wrote: >>> 2014-06-18 11:57 GMT+04:00 Konstantin Kolinko >>> <knst.koli...@gmail.com>: >>>>> >>>>> HTTP/1.1 302 Found Set-Cookie: >>>>> JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; >>>>> Expires=Thu, 01-Jan-1970 00:00:10 GMT Pragma: No-cache >>>>> Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 >>>>> UTC Set-Cookie: >>>>> JSESSIONID=235F4293591E5C72859317ED3294C5A5; Path=/admin; >>>>> Secure; HttpOnly Location: https://X.Y.A.B/admin/login.jsp >>>>> Content-Length: 0 Date: Tue, 17 Jun 2014 16:21:17 GMT >>>>> Server: XYZ >>>>> >>>> >>>> With that value of "Expires" the cookie is actually being >>>> cleared, not set. >>>> >>> >>> The 'Secure' flag says that the browser should never send the >>> cookie to the server over a non-secure connection. >>> >>> When the cookie is being cleared, the "Secure" flag is >>> irrelevant, as the cookie will not be sent back by the >>> browser. >> >> +1 >> >>> The "HttpOnly" flag says that the cookie should not be >>> accessible from Javascript code running in the browser. If the >>> cookie is being deleted, is there a way to access it from >>> Javascript? I think that there is no such way. >> >> +1 >> >> I think this is a spurious error being flagged by the security >> scanner. Adding "HttpOnly" and "Secure" flags to the "expire" >> Set-Cookie header is just a waste of bytes because they have no >> effect whatsoever on what the client does with the cookie (it >> always deleted it, unless the system clock is set horribly >> wrong). > > I haven't followed all of this discussion, but as for deleting a > Cookie, I think the problem is that there isn't an explicit > "Delete-Cookie" header; but instead the server has to send the > cookie name with a "Expires" flag that is in the past. Correct. > In this case, I think if the original cookie contained a "Secure" > and "HttpOnly" flag, then the Set-Cookie header which deletes the > cookie by setting an "Expire" date in the past also should set the > "Secure" and "HttpOnly" flags. The point is that the "Secure" and "HttpOnly" flags are irrelevant if the cookie is being expired. > Although it is unlikely that the client will send back a Cookie > which expires in 1970, it would be possible if the client's system > date is set wrong, so IMHO this is not an exact "delete this > cookie" instruction and therefore the "Expire" Set-Cookie header > should include the same HttpOnly and Secure flags that were > included in the original Set-Cookie header. I wonder if the spec says something about the minimum date of the Expires attribute. I'm not going to look it up, but I'll bet that Expires values prior to start-of-UNIX-epoch are invalid, so basically timestamp=0l is, by definition, an expire operation regardless of the client's current clock. > Also, when deleting a cookie, I think it might be better to send a > Set-Cookie header with an empty value, so that the value is > overwritten by the browser if for some reason the cookie is not yet > expired. > > E.g., instead of Set-Cookie: > JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, > 01-Jan-1970 00:00:10 GMT the server could send: Set-Cookie: > JSESSIONIDSSO=; Expires=Thu, 01-Jan-1970 00:00:10 GMT > > (RFC6265 Section 3.1 shows an example where a cookie is deleted > this way) Seems like a reasonable request, although it should not matter one bit. Want to create a BZ request for this? Perhaps even a patch? ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTowRYAAoJEBzwKT+lPKRYUmkP/1csmbspAUI0PE8DlZukTMN6 jOKFJMJIJxTv3zOZc7jcDnUvXAwqrLvgxfylDim1MItEhhGfioi0LhCIjXuU7k9f SyWG3l+pCJmYx68qXeOcyky7QVuWsVMtFhx/gqS5s3eFpoipq5Y74XQIOvq6CQ75 18HA7R6vXB5mtTJwvd59ICwitVmoQrYPNCF8HLnFVHLCvPYeeRVBt9PgDL7nMLRo 7viE5QIFII2G/ss5sRXzFRTHkV9xrwZ9J0N4q5+ivVr47CakLwzJLh2NUbExXL+u gYfLKaVH2A6pCEacOtQgeamv6DTiKe+xdyclgyERRD04tQtjnGe1rIrH7ndwbH7z Gz28BiNPGKF5vGerWcIRngPZ0/uHRVgc5/F8TytbEHVTFVTSXZq70jl2wEzMCXRk C5iEXkyBLX7EmnnwAvCKKHc23vFMQG63Un4afHNXr7rabD8zQIeg5c9kEyDf9epx rnePt4tgSv9ajWpSpUMqcHlZhVPk4GtdmrGQ+1blr4iygvwmf0Ew2is5nZOB2SVC 0Jz3/D40VrwkMHEv7wXPsZueMhX33yCTnavGuV5zerg1VpF1ghjcz1dxsEE6KJlS VK8NPSr8zDvdBwvIeNFMT26frK11IQcwWohbQyJCkpOh8vKV9kI00yIPqQG9ccSg H7OXzMdSg9Rph+ANAsjd =wLAE -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
