This probably just needs some cleanup in the codebase - can you please open a Jira issue for this?
-- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Mon, Sep 22, 2014 at 2:15 AM, sganslandt <[email protected]> wrote: > Hi, > > End of last week we started getting problems with logged in sessions on our > site for customers on Safari/iOS8. The problem was found to be caused by > the > existence of multiple Set-Cookie headers for the same domain in the > response > headers of the login request. To be more specific, one sessionId=deleteMe > and one sessionId='actual session id'. We've noted this before and thought > it was a bit strange, but it seems to have worked everywhere so we didn't > really think that much more about it. > > According to http://tools.ietf.org/html/rfc6265 > <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. > So the sorting in the client can not be depended on (at least when it comes > to Safari on iOS 8, which is bound to be a pretty significant share of the > clients out there shortly). > > Maybe I'm getting ahead of myself, the reason for the two Set-Cookie > headers > to show up in the first place is that we're making sure to end any already > existing session on login requests, authorized or not, to make sure that > the > logged in session will definitely be a fresh one. The means of doing that > is > (more or less) > public boolean login() { SecurityUtils.getSubject() session.stop() > UsernamePasswordToken token = new UsernamePasswordToken(username, > plaintextPassword); subject.login(token);} > We've deployed a workaround with our own Cookie implementation which > extends > SimpleCookie and just overrides > public void removeFrom(HttpServletRequest request, HttpServletResponse > response) > with an implementation that does nothing. This works, so far, but it > definitely feels a bit sketchy. > So, are we doing it wrong or could this be something that might be possible > to solve in Shiro? Wouldn't it be better to follow the SHOULD NOTs and only > send either a new sessionId or a sessionId=deleteMe, depending on whether a > new session was started by the deleting request or not? > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Regarding-multiple-Set-Cookie-headers-and-Safari-on-iOS-8-tp7580252.html > Sent from the Shiro User mailing list archive at Nabble.com. >
