You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by sganslandt <se...@ganslandt.nu> on 2014/09/22 11:15:32 UTC
Regarding multiple Set-Cookie headers and Safari on iOS 8
Hi,
End of last week we started getting problems with logged in sessions on our
site for customers on Safari/iOS8. The problem was found to be caused by the
existence of multiple Set-Cookie headers for the same domain in the response
headers of the login request. To be more specific, one sessionId=deleteMe
and one sessionId='actual session id'. We've noted this before and thought
it was a bit strange, but it seems to have worked everywhere so we didn't
really think that much more about it.
According to http://tools.ietf.org/html/rfc6265
<http://tools.ietf.org/html/rfc6265> , "Servers SHOULD NOT include more
than one Set-Cookie header field in the same response with the same
cookie-name.". If they do, the client can/will just override the cookie
value from subsequent Set-Cookie headers. Sending multiple Set-Cookie
headers would then make the correct functionality be dependent on the client
sorting the headers correctly which brings us to (from the same RFC)
2. The user agent SHOULD sort the cookie-list in the following order:
* Cookies with longer paths are listed before cookies with shorter
paths. * Among cookies that have equal-length path fields, cookies
with earlier creation-times are listed before cookies with later
creation-times. NOTE: Not all user agents sort the cookie-list in this
order, but this order reflects common practice when this document was
written, and, historically, there have been servers that (erroneously)
depended on this order.
So the sorting in the client can not be depended on (at least when it comes
to Safari on iOS 8, which is bound to be a pretty significant share of the
clients out there shortly).
Maybe I'm getting ahead of myself, the reason for the two Set-Cookie headers
to show up in the first place is that we're making sure to end any already
existing session on login requests, authorized or not, to make sure that the
logged in session will definitely be a fresh one. The means of doing that is
(more or less)
public boolean login() { SecurityUtils.getSubject() session.stop()
UsernamePasswordToken token = new UsernamePasswordToken(username,
plaintextPassword); subject.login(token);}
We've deployed a workaround with our own Cookie implementation which extends
SimpleCookie and just overrides
public void removeFrom(HttpServletRequest request, HttpServletResponse
response)
with an implementation that does nothing. This works, so far, but it
definitely feels a bit sketchy.
So, are we doing it wrong or could this be something that might be possible
to solve in Shiro? Wouldn't it be better to follow the SHOULD NOTs and only
send either a new sessionId or a sessionId=deleteMe, depending on whether a
new session was started by the deleting request or not?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Regarding-multiple-Set-Cookie-headers-and-Safari-on-iOS-8-tp7580252.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Regarding multiple Set-Cookie headers and Safari on iOS 8
Posted by Les Hazlewood <lh...@apache.org>.
Thank you!
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Mon, Sep 29, 2014 at 1:17 AM, sganslandt <se...@ganslandt.nu> wrote:
> Ok, thanks for the reply. Issue created -
> https://issues.apache.org/jira/browse/SHIRO-520.
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Regarding-multiple-Set-Cookie-headers-and-Safari-on-iOS-8-tp7580252p7580265.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Regarding multiple Set-Cookie headers and Safari on iOS 8
Posted by sganslandt <se...@ganslandt.nu>.
Ok, thanks for the reply. Issue created -
https://issues.apache.org/jira/browse/SHIRO-520.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Regarding-multiple-Set-Cookie-headers-and-Safari-on-iOS-8-tp7580252p7580265.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Regarding multiple Set-Cookie headers and Safari on iOS 8
Posted by Les Hazlewood <lh...@apache.org>.
This probably just needs some cleanup in the codebase - can you please open
a Jira issue for this?
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Mon, Sep 22, 2014 at 2:15 AM, sganslandt <se...@ganslandt.nu> wrote:
> Hi,
>
> End of last week we started getting problems with logged in sessions on our
> site for customers on Safari/iOS8. The problem was found to be caused by
> the
> existence of multiple Set-Cookie headers for the same domain in the
> response
> headers of the login request. To be more specific, one sessionId=deleteMe
> and one sessionId='actual session id'. We've noted this before and thought
> it was a bit strange, but it seems to have worked everywhere so we didn't
> really think that much more about it.
>
> According to http://tools.ietf.org/html/rfc6265
> <http://tools.ietf.org/html/rfc6265> , "Servers SHOULD NOT include more
> than one Set-Cookie header field in the same response with the same
> cookie-name.". If they do, the client can/will just override the cookie
> value from subsequent Set-Cookie headers. Sending multiple Set-Cookie
> headers would then make the correct functionality be dependent on the
> client
> sorting the headers correctly which brings us to (from the same RFC)
>
> 2. The user agent SHOULD sort the cookie-list in the following
> order:
> * Cookies with longer paths are listed before cookies with
> shorter
> paths. * Among cookies that have equal-length path fields, cookies
> with earlier creation-times are listed before cookies with later
> creation-times. NOTE: Not all user agents sort the cookie-list in
> this
> order, but this order reflects common practice when this document was
> written, and, historically, there have been servers that
> (erroneously)
> depended on this order.
> So the sorting in the client can not be depended on (at least when it comes
> to Safari on iOS 8, which is bound to be a pretty significant share of the
> clients out there shortly).
>
> Maybe I'm getting ahead of myself, the reason for the two Set-Cookie
> headers
> to show up in the first place is that we're making sure to end any already
> existing session on login requests, authorized or not, to make sure that
> the
> logged in session will definitely be a fresh one. The means of doing that
> is
> (more or less)
> public boolean login() { SecurityUtils.getSubject() session.stop()
> UsernamePasswordToken token = new UsernamePasswordToken(username,
> plaintextPassword); subject.login(token);}
> We've deployed a workaround with our own Cookie implementation which
> extends
> SimpleCookie and just overrides
> public void removeFrom(HttpServletRequest request, HttpServletResponse
> response)
> with an implementation that does nothing. This works, so far, but it
> definitely feels a bit sketchy.
> So, are we doing it wrong or could this be something that might be possible
> to solve in Shiro? Wouldn't it be better to follow the SHOULD NOTs and only
> send either a new sessionId or a sessionId=deleteMe, depending on whether a
> new session was started by the deleting request or not?
>
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Regarding-multiple-Set-Cookie-headers-and-Safari-on-iOS-8-tp7580252.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>