Rails sessions current practices
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?
Solution 1:
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
Solution 2:
Cookies are encrypted by default in Rails 4
In Rails 4, CookieStore cookies are encrypted and signed by default:
If you only have
secret_tokenset, your cookies will be signed, but not encrypted. This means a user cannot alter theiruser_idwithout knowing your app's secret key, but can easily read theiruser_id. This was the default for Rails 3 apps.
If you have
secret_key_baseset, 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_tokenandsecret_key_baseset, 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.
Solution 3:
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.
Solution 4:
FWIW, rails 3.1 suggests running
rails generate session_migration
However this generates the exact same migration as
rake db:sessions:create
Solution 5:
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.