FastMail and sessions

FastMail handles sessions slightly differently to most other web services, and coincidentally I’ve had a few questions about this recently, so I thought I’d write a blog post explaining what we do.

For most web services, the concept of a session is something like this:

1. A user goes to site http://example.com for the first time in their
   browser
2. The server detects that the user has no existing session cookie, so
   it creates a new session on the server, and sends back a cookie to
   the browser (simply a string) that uniquely identifies that session
3. After that, for every page within the example.com domain that the
   user goes to, the browser sends the cookie back to the server with
   every request, so the application can get the session data stored on
   the server

This process is very important, because it allows the server to keep track of things for each user separately, even though they’re going to the same hostname or url path.

Because each cookie is usually associated with a domain, that usually limits you to one session per domain. So for instance when you use google or yahoo, you can only every be logged into one account at a time. There are certain things that work around this, like Mozilla Prism, or Chrome Incognito Window, but these work by creating entirely separate cookie jars, so you can log into different accounts at the same time.

FastMail does things a bit differently. It starts off the same, so when you go to http://www.fastmail.fm, it creates a new session and associated cookie. However when you login to your account, it does two things:

1. It renames the cookie so the cookie itself has a unique name with a
   random value (we call this the cookie “salt”)
2. It redirects you to a new URL that includes the salt value in the
   URL, and all further URLs as you move around the interface include
   this salt value

What this means is that if you go to http://www.fastmail.fm and login, and then open a new tab, and go to http://www.fastmail.fm again, you’ll see the login screen again, and be able to login to the same account or a completely different account, and happily access both accounts in the separate tabs with separate sessions at the same time without them affecting each other!

On top of that, FastMail tries to store most “state” information (such as which folder you’re in, what message you’re viewing, etc) in each URL rather than on the server in the session. What this means is that in many places, you can happily right-click a link and select “Open in new tab” or “Open in new window”, and although the newly opened tab/window will share the same session with the original tab/window, they won’t interact with each other.

For instance, if you go to your Inbox and read a message, and then right-click on the “Trash” folder and select “Open in new tab”, you’ll end up with a new tab looking at messages in the Trash folder. You can then switch between the first tab and second tab, moving between folders, reading messages, and neither action will affect what happens in the other tab. (There are a few small situations where this isn’t the case, but these are rarer used functionality, and most people won’t see it)

Session oddities

This difference in approach does result in some things being different to most other websites

1. If you use the “Long term” login option on the login screen, that
   doesn’t actually mean you get a long term session (well, you do get
   an 8 hour session instead of a 2 hour session, but the fact it logs
   you in automatically forever is separate). Instead a separate cookie
   is stored on your machine with your username and encrypted password,
   and each time you go to http://www.fastmail.fm, it creates a new
   login and new session
2. Because of browser limits with the number of cookies you can have
   per-site, if you create many logins and many sessions (eg. open many
   separate tabs and login separately with each one), then we will
   start to expire old sessions to avoid you running out of cookies and
   new session failing. This starts to happen if you have > 10
   simultaneous session cookies, we’ll start to expire the oldest ones.
   This can manifest itself as tabs where you’ve definitely been idle
   < 2 hours suddenly reporting your session as “expired” on the next
   link/button you click

Most of the time users don’t need to know about or worry about any of this, things should “just work”, but there are some edge cases where knowing the underlying cause of things can help explain some odd cases.