You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Sebastian Ganslandt (JIRA)" <ji...@apache.org> on 2014/09/29 10:16:33 UTC
[jira] [Updated] (SHIRO-520) Multiple Set-Cookie headers for the
same cookie
[ https://issues.apache.org/jira/browse/SHIRO-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebastian Ganslandt updated SHIRO-520:
--------------------------------------
Description:
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.
was:
When stopping an old session and starting a new one in the same API request like
public boolean login() {
SecurityUtils.getSubject()
session.stop()
UsernamePasswordToken token = new UsernamePasswordToken(username, plaintextPassword);
subject.login(token);
}
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.
> 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)