Modes of Current Practice

Question

Anyone have any best practice guidelines for Rails and sessions? The default session type for Rails 3 is still the CookieStore, isn't it? I used SqlSessionStore for a while and it worked well, but I can move away from this in favor of CookieStore.

Is it not recommended to use CookieStore to receive confidential information, even with salted information, or is it better to store it in the database?

Answer 1

Use the database for sessions, not cookies, which should not be used to store sensitive information.

Create a session table with

rake db:sessions:create 

Start the migration

 rake db:migrate 

Make sure you also point the rails to using ActiveRecord to manage your sessions.

Rails 3

configurations / 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 

Answer 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_token , your cookies will be signed but not encrypted. This means that the user cannot change his user_id without knowing your app secret key, but can easily read their user_id . This was the default for Rails 3 applications.

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

If you have both secret_token and secret_key_base , your cookies will be encrypted and the signed cookies created by Rails 3 will be transparently read and encrypted to ensure a smooth update path.

Active recording session store deprecated in Rails 4

This answer is now deprecated in relation to Rails 4. Active record The session log is deprecated and removed from Rails, so the following generators will no longer work:

• rake db:sessions:create

• rails generate session_migration

This has been indicated in this answer . The reason the active Session Storage entry was deprecated because reading / writing to the database is not good when you have a large number of users accessing your application, as outlined in this blog post :

... one important issue with Active Record session storage is that it is not scalable. This creates an unnecessary load on your database. As soon as your application receives a large amount of traffic, the session database table is continuously bombarded by read / write operations.

With Rails 4, the Active Record session store is removed from the kernel and is now deprecated.

If you still want to use the Active Record session store, it is still available as a gem .

Recommendations for working with current rails

For more up-to-date best practices for Ruby on Rails sessions, I suggest you check out the latest versions of the Ruby on Rails Security Guide .

Answer 3

I do not believe that everything has changed in the way anyone on any platform should handle cookie-based sessions. Be skeptical of anything that goes beyond server control (cookies, form messages, etc.). This is a general principle of web development.

As far as I know, encryption has not changed on this front.

Something to keep in mind in the cookie repository is limiting the amount of data and the information received that this data will be sent by wire in each request, where, since the database repository transmits only the identifier and data on the server.

Answer 4

FWIW Rails 3.1 Offer Launch

 rails generate session_migration 

However, this gives rise to the same movement as

 rake db:sessions:create 

Answer 5

By default, I really like Rails values. CookieStore is fast and should cover most use cases. Of course, you are limited to 4kb, and your data will be visible to the user, but the Rails path should only use a session for things like integer identifiers and basic string values. If you are trying to store objects or sensitive information in a session, you are probably doing it wrong.