[
https://issues.apache.org/jira/browse/SHIRO-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151502#comment-14151502
]
Sebastian Ganslandt commented on SHIRO-520:
-------------------------------------------
In this case, it's not a logout but a login that ends the old session just in
case it had been previously used for an authenticated session but for some
reason hadn't been removed from the client.
I don't think your your suggestion applies to that case, as that would mean
that logins would have to first redirect the client to a "proper" logout before
actually logging in, which would make the login quite a bit heavier. But please
enlighten me if I'm missing something :).
> Multiple Set-Cookie headers for the same cookie
> -----------------------------------------------
>
> Key: SHIRO-520
> URL: https://issues.apache.org/jira/browse/SHIRO-520
> Project: Shiro
> Issue Type: Bug
> Components: Web
> Affects Versions: 1.2.1, 1.2.2
> Reporter: Sebastian Ganslandt
>
> When stopping an old session and starting a new one in the same API request
> like
> {noformat}
> public boolean login() {
> SecurityUtils.getSubject()
> session.stop()
> UsernamePasswordToken token = new UsernamePasswordToken(username,
> plaintextPassword);
> subject.login(token);
> }
> {noformat}
> the response headers will include two Set-Cookie entries, one which removes
> the old session id (value=deleteMe and expiryTime=<in the past>) and one
> which sets the new session id. This seems to have been fine previously but
> for example Safari on iOS 8 seems to reverse the order of them when handling
> the response and effectively making it impossible to stay authenticated.
> According to 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.
> For (just a little) more context, see
> http://shiro-user.582556.n2.nabble.com/Regarding-multiple-Set-Cookie-headers-and-Safari-on-iOS-8-td7580252.html.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
