If you manage a Shibboleth SP and have been receiving complaints from Firefox 5 users, you may be running into an issue due to FF5’s more compliant caching of Location headers in 302 redirects. While this is a step in the right direction for front-end performance, even tiny HTTP handling changes can affect existing sites.
By now, Opera’s invention of restoring tabs automatically is available in most browsers, but unlike every other browser,
Firefox’s restored tabs retain session cookies for the domains of the saved tabs Firefox restores all session cookies as if the browser were never closed. This is handy in some ways, but dangerous in others:
It’s fooling web developers by breaking a very old and widely-known convention. Since Netscape’s original spec (around 1994) a cookie with an empty/missing
expires was to be discarded “when the user’s session ends” (later clarified as “when the user agent exits” in RFC2109), and thousands of prominent web pages describe “session cookies” this way.
A common session design pattern uses a persistent cookie to establish low-level identity info and a session cookie for full authentication. Developers may not know that their full auth period may be lasting days or weeks, including trips to insecure wifi spots, browsing by multiple users, etc.
It’s fooling users. No one thinks of a single browsing “session” as encompassing several days of browser usage
just because the same tabs were open, and users frequently read that they need to simply exit their browser to ensure their session is ended.
- Be aware that Firefox session cookies can linger for days, despite the user having closed their browser.
- Manage session timeouts on the server-side and/or via HMAC-signed timestamp values in the cookie contents (don’t let the client decide how long a session should last).
If you can, includeRealize that in later FF versions, “secure” cookies also are restored.
securein the cookie header. Firefox does not restore HTTPS session cookies.
- If you give out session cookies with unique names, have your application clean these up when they’re no longer needed. If you don’t, your Firefox users could suffer from…
Cookie Accumulation Torment
This annoying situation occurs when Firefox gains so many local cookies that the web server begins to deny all your requests. Deleting some or all these cookies is the only way to fix the issue because—yay—the problem session cookies persist across browser, and even OS, restarts.
Big Shibboleth Implications
If your Shibboleth-authenticating app maintains its own session, make sure that the “sign out” function searches for and deletes the local Shibboleth cookies (or that the SP sets only “secure” cookies). Otherwise this could happen:
- Jane “signs out”, closes Firefox, and lends her computer to Sally.
- Sally opens Firefox and clicks “sign in”.
- Sally is instantly authenticated into Jane’s account!
Jane’s application session was over, but Firefox allowed her Shibboleth session to live on.
Also, since Shibboleth gives out uniquely-named session cookies (prepended with
_shibstate), failing to clean these up will lead Firefox users to the aforementioned torment. If the user has an app open all day every day, count on her gaining at least one cookie per day.