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