Rails sessions current practices

Question

Anyone have any "best practices" tips for Rails and sessions? The default session type for Rails 3 is still CookieStore, right? I used SqlSessionStore for a while and it worked well, but I may move away from that in favor of CookieStore.

Is it still not a good idea to use CookieStore for sensitive info, even with salted info or is that better stored in the DB?

Also, what are the current thoughts around using Memcached for session storage? — Lukas, Dec 09 '10 at 16:25
Related: [rails 4.0, rake db:sessions:create](http://stackoverflow.com/questions/17655744/rails-4-0-rake-dbsessionscreate). — , Apr 18 '14 at 22:20

score 102 · Accepted Answer · edited Feb 13 '11 at 11:13

102

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

edited Feb 13 '11 at 11:13

Diego Pino

11,278
1
55
57

answered Aug 25 '10 at 07:45

Volcanic

1,572
1
13
5

3

I last heard ARstore for sessions was super slow. anyone know of benchmarks? – Lukas Aug 25 '10 at 20:49
So after you make those changes and configurations. You can start to use sessions[:test] = 5? Thanks – RoR Sep 17 '10 at 19:07
4

If you watch the sessions table growth and setup a job to prune it accordingly you won't have performance issues. – Bill Leeper Mar 28 '12 at 21:50
3

Does this conflicts with devise? – damuz91 Jun 14 '12 at 03:07
4

Over here, Rails 3.2, it is something like TheNameOfMyApplication::Application.config.session_store :active_record_store – Eduardo Jan 10 '13 at 04:02
db sessions = performance hit for questionable gain? Haven't yet seen compelling real-world reasons to use it, though would be interested to hear about some. – Yarin Sep 12 '13 at 04:03
4

The `rake db:sessions:create` is deprecated and removed in Rails 4, because it doesn't scale well for applications with many users (too many database reads and writes). See [rails 4.0, rake db:sessions:create](http://stackoverflow.com/a/17656159/456814). – Apr 18 '14 at 22:29

score 55 · Answer 2 · edited Nov 19 '21 at 01:06

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.

score 9 · Answer 3 · answered Apr 06 '10 at 21:12

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.

score 4 · Answer 4 · answered Feb 21 '12 at 22:11

4

FWIW, rails 3.1 suggests running

rails generate session_migration

However this generates the exact same migration as

rake db:sessions:create

answered Feb 21 '12 at 22:11

Nate Milbee

81
4

On the same note, the rake task `db:sessions:create` now directly invokes the `session_migration` generator. task :create => :environment do raise "Task unavailable to this database (no migration support)" unless ActiveRecord::Base.connection.supports_migrations? require 'rails/generators' Rails::Generators.configure! require 'rails/generators/rails/session_migration/session_migration_generator' Rails::Generators::SessionMigrationGenerator.start [ ENV["MIGRATION"] || "add_sessions_table" ] end – slant Sep 14 '12 at 20:29
The `rake db:sessions:create` and `rails generate session_migration` generators are deprecated and removed in Rails 4, because they don't scale well for applications with many users (too many database reads and writes). See [rails 4.0, rake db:sessions:create](http://stackoverflow.com/a/17656159/456814). – Apr 18 '14 at 22:30

score 2 · Answer 5 · answered Sep 12 '13 at 03:48

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.