Rails会议的当前做法

是否有人对Rails和会话有“最佳实践”技巧？Rails 3的默认会话类型仍然是CookieStore，对吗？我使用SqlSessionStore已有一段时间，并且效果很好，但是我可能会改用CookieStore来代替它。

使用CookieStore获取敏感信息（即使是含盐信息）还是不是一个好主意，还是更好地存储在数据库中？

使用数据库进行会话，而不要使用基于cookie的默认值，该默认值不应用于存储高度机密的信息

使用创建会话表

rake db:sessions:create

运行迁移

rake db:migrate

确保您还告诉Rails也使用ActiveRecord来管理会话。

导轨3

config / initializers / session_store.rb：

Rails.application.config.session_store :active_record_store

滑轨2

config / environment.rb：

config.action_controller.session_store = :active_record_store

Cookie在Rails 4中默认加密

在Rails 4中，默认情况下，CookieStore cookie被加密并签名：

如果只进行secret_token设置，则将对Cookie进行签名，但不会对其进行加密。这意味着用户无法在user_id不知道您应用程序的密钥的情况下更改其密码，但可以轻松读取其密码user_id。这是Rails 3应用程序的默认设置。

如果已secret_key_base设置，您的cookie将被加密。这与签名的cookie相比更进一步，因为加密的cookie无法由用户更改或读取。这是从Rails 4开始的默认设置。

如果同时设置了两者secret_token，secret_key_base则将对cookie进行加密，并且将透明地读取和加密由Rails 3生成的签名cookie，以提供一个平滑的升级路径。

Active Record会话存储在Rails 4中已弃用

现在，有关Rails 4的答案已经过时了。Active Record Session Store已过时并已从Rails中删除，因此以下生成器将不再起作用：

• rake db:sessions:create

• rails generate session_migration

这个答案指出了这一点。不推荐使用Active Record会话存储区的原因是，如本文博文所述，当您有大量用户访问应用程序时，对数据库的读/写不能很好地扩展：

... Active Record会话存储的一个主要问题是它不可扩展。它将对您的数据库造成不必要的负载。一旦您的应用程序接收到大量流量，会话数据库表就会被读/写操作连续轰炸。

从Rails 4开始，Active Record会话存储已从核心框架中删除，现在已弃用。

如果您仍然想使用Active Record会话存储，它仍然可以作为gem使用。

当前的Rails会话最佳实践

有关Ruby on Rails会话的最新最佳实践，建议您查看Ruby on Rails安全指南的最新版本。

我不相信任何平台上的任何人如何处理基于cookie的会话都不会改变。怀疑超出服务器控制范围的所有内容（cookie，表单发布等）。这就是Web开发的一般原理。

就加密而言，我不知道在这方面是否有任何更改。

Cookie存储区要注意的一点是数据量的限制，以及在每个请求中都会在线发送此数据的陷阱，因为数据库存储区仅在其中传输ID，并且数据保存在服务器上。

FWIW，rails 3.1建议运行

rails generate session_migration

但是，这会产生与迁移完全相同的迁移

rake db:sessions:create

Rails的默认设置对我来说似乎非常好-CookieStore速度很快，应该可以覆盖大多数用例。确保您限制为4kb，并且您的数据对用户可见，但是Rails的方法是仅将会话用于整数ID和基本字符串值之类的内容-如果您尝试在会话中存储对象或高度机密信息您可能做错了。