Question

We have found an issue in our app where Safari on the Mac randomly recreates a login cookie from a logged off session.

I have a fiddler archive with this behaviour here. Note that some stuff has been removed from this to make it easier to get, but nothing which sets a cookie or anything has been taken out – only repetitions of requests 3-8.

I’ll talk you through the running order

• Request 1: user logs out via call to /logout.aspx – Set-Cookie returned setting cookie expiry date to 1999
• Requests 2-8: user refreshes login page sending calls to root or /res/en-US/s.js – no cookie is sent to server or received back, and access is denied. I have cut out a lot of requests of this nature from the log as they are boring
• Request 9: request for /res/en-US/s.js – Hv3 authentication cookie has mysteriously reappeared! Wat. There was NO set-cookie! WTFF!
• Request 10+ : now the cookie has reappeared, the site logs the user in AGAIN

The cookie, when examined in Safari looks like

<dict>
    <key>Created</key>
    <real>259603523.26834899</real>
    <key>Domain</key>
    <string>.mysite.dev</string>
    <key>Expires</key>
    <date>2010-03-24T16:05:22Z</date>
    <key>HttpOnly</key>
    <string>TRUE</string>
    <key>Name</key>
    <string>.Hv3</string>
    <key>Path</key>
    <string>/</string>
</dict>

One thing to note is that in Safari, the cookie domain is .mysite.dev not mysite.dev (which is the cookie domain specified in web.config) – however, given that access is denied in requests 2-8, it looks like the cookie has expired OK. If you look in the list of cookies in the browser during 2-8, the .Hv3 cookie is not there.

Is this our bug or Safari’s?
What can I do to stop it happening?

Answer 1

There are known problems with certain browsers cookie handling.

See the following paper:
iSEC Cleaning Up After Cookies

Also see this discussion on Apple.com regarding the case of the reappearing cookie.