Rails sessions current practices

Question

Use the database for sessions instead of the cookie-based default, which shouldn't be used to store highly confidential information

Create the session table with

rake db:sessions:create

Run the migration

rake db:migrate

Make sure you also tell rails to use ActiveRecord to manage your sessions too.

Rails 3

config/initializers/session_store.rb:

Rails.application.config.session_store :active_record_store

Rails 2

config/environment.rb:

config.action_controller.session_store = :active_record_store

Cookies are encrypted by default in Rails 4

In Rails 4, CookieStore cookies are encrypted and signed by default:

If you only have secret_token set, your cookies will be signed, but not encrypted. This means a user cannot alter their user_id without knowing your app's secret key, but can easily read their user_id. This was the default for Rails 3 apps.

If you have secret_key_base set, your cookies will be encrypted. This goes a step further than signed cookies in that encrypted cookies cannot be altered or read by users. This is the default starting in Rails 4.

If you have both secret_token and secret_key_base set, your cookies will be encrypted, and signed cookies generated by Rails 3 will be transparently read and encrypted to provide a smooth upgrade path.

Active Record Session Store is Deprecated in Rails 4

This answer is now out-of-date with regard to Rails 4. The Active Record Session Store has been deprecated and removed from Rails, so the following generators will no longer work:

• rake db:sessions:create

• rails generate session_migration

This was pointed out in this answer. The reason that the Active Record Session Store was deprecated is because the reads/writes to the database don't scale well when you have a large number of users accessing your application, as stated in this blog post:

...one major issue with the Active Record session store is that it is not scalable. It puts an unnecessary load on your database. Once your application receives a large amount of traffic, the sessions database table is continuously bombarded with read/write operations.

As of Rails 4, the Active Record session store has be removed from the core framework and is now deprecated.

If you still want to use the Active Record Session Store, it's still available as a gem.

Current Rails Session Best Practices

For more current best practices for Ruby on Rails sessions, I advise that you check out the lastest versions of the Ruby on Rails Security Guide.

I don't believe anything has changed in how anyone on any platform should handle cookie based sessions. Be skeptical of anything that passes beyond the server's control (cookies, form posts, etc.) Thats a general principle of web development.

As far the encryption, I don't know if anything has changed on that front.

Something to be mindful of with a cookie store is the limit to the amount of data, and the gotcha that this data will be sent on the wire in every request, where as a database store only transfers the id and the data lives on the server.

FWIW, rails 3.1 suggests running

rails generate session_migration

However this generates the exact same migration as

rake db:sessions:create

The Rails defaults seem pretty good to me- The CookieStore is fast and should cover the majority of use cases. Sure you're limited to 4kb and your data will be visible to the user, but the Rails way is to only use session for things like integer IDs and basic string values- If you're trying to store objects or highly confidential information in session you're probably doing it wrong.