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.
