How does the Rails “session” work?

If you want to store some temporary information about your user, such as who they are (if they’re logged in), the natural place to store it is in Rails’ session.

This is a temporary storage area that is tied to a particular browser session (so the same person on a different browser would have a different session).

Of course you could do all of this using cookies. A cookie is stored on the user’s machine and sent back and forth with each request – you could store the logged in user’s ID in a cookie, read it in a before_filter and you magically know who the logged in user is. As the cookie is on the user’s machine, you never have to worry about how much server storage you are using either.

One problem with this – cookies are just text files and can be read by pretty much anyone. Not very secure.

There are also a few other issues with cookies, not least, they can only hold a small amount of data. But if all you are holding is a User ID then that’s fine.

Instead of using cookies, Rails gives you the option of using the session. By default, this is actually implemented using cookies – so what’s the difference? Well, Rails encodes the contents of the cookie and then uses a digest to make sure that the contents aren’t tampered with. But it’s still just encoding the contents of the session cookie, so it’s not really that secure.

However, we have more options. You don’t need to store the session information in a cookie – instead you can use your cache, if you have one, or your database.

In both cases, a cookie is still used, but it just stores a session-id – which is meaningless to any attackers (not strictly true, but it takes a more advanced attack to take advantage of it). This session-id is then used as a key into the actual storage mechanism.

If you have memcache running on your server and configured in your Rails app (and you probably should do as it makes a big difference to performance for virtually no effort), you can store your session data in there. This is fast (important for something that is likely to be accessed on every single request) and you never have to worry about storage; part of how memcache works is if it runs out of space, it clears out the oldest, least-recently used items. That’s both an advantage and a disadvantage – if you get a sudden rush of users, there’s a chance that people who are logged in just get kicked out as memcache clears out old data. Not likely, but a possibility.

Another alternative is to use your database. Rails can use an ActiveRecord session store, that creates a table called sessions to store your data. This is slower than memcache but has the advantage that the data stays there until you clear it out. This also has the disadvantage that the data stays there until you clear it out – I normally set up a rake task that deletes session records that haven’t been touched in N days to prevent the table growing to a huge size.

So there you have it – if you need to store temporary information related to the current user, the session is the place to store it. If it’s only small and you’re not too worried about the security of that information, the default cookie store will be fine. If you’re not worried about the duration that your information is stored for, memcache is a great contender. And if you are storing sensitive information in your database, or it’s a large structure, your database is the place to keep it all safe.

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe