Return-Path: 
 <dev-return-6227-apmail-shiro-dev-archive=shiro.apache.org@shiro.apache.org>
X-Original-To: apmail-shiro-dev-archive@www.apache.org
Delivered-To: apmail-shiro-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 1C5C317714
	for <apmail-shiro-dev-archive@www.apache.org>;
 Mon, 29 Sep 2014 08:49:34 +0000 (UTC)
Received: (qmail 9851 invoked by uid 500); 29 Sep 2014 08:49:34 -0000
Delivered-To: apmail-shiro-dev-archive@shiro.apache.org
Received: (qmail 9828 invoked by uid 500); 29 Sep 2014 08:49:34 -0000
Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@shiro.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@shiro.apache.org>
List-Post: <mailto:dev@shiro.apache.org>
List-Id: <dev.shiro.apache.org>
Reply-To: dev@shiro.apache.org
Delivered-To: mailing list dev@shiro.apache.org
Received: (qmail 9817 invoked by uid 99); 29 Sep 2014 08:49:33 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2014 08:49:33 +0000
Date: Mon, 29 Sep 2014 08:49:33 +0000 (UTC)
From: "Sebastian Ganslandt (JIRA)" <jira@apache.org>
To: dev@shiro.apache.org
Message-ID: <JIRA.12744609.1411978484000.144301.1411980573855@Atlassian.JIRA>
In-Reply-To: <JIRA.12744609.1411978484000@Atlassian.JIRA>
References: <JIRA.12744609.1411978484000@Atlassian.JIRA>
 <JIRA.12744609.1411978484495@arcas>
Subject: [jira] [Commented] (SHIRO-520) Multiple Set-Cookie headers for the
 same cookie
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


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