Rails 会话当前实践

有人对 Rails 和会话有什么“最佳实践”提示吗?Rails 3的默认会话类型仍然是 CookieStore,对吗?我曾经使用过 SqlSessionStore 一段时间,它工作得很好,但我可能会放弃它,转而使用 CookieStore。

对于敏感信息使用 CookieStore 是不是仍然不是一个好主意,即使存储在数据库中也是如此吗?

48407 次浏览

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.

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

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.

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.