shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebastian Ganslandt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SHIRO-520) Multiple Set-Cookie headers for the same cookie
Date Mon, 29 Sep 2014 08:49:33 GMT

    [ 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)

Mime
View raw message