Rails 中的会话和 cookie 如何工作？
How do sessions and cookies work in Rails?
我已经使用 Devise 一段时间来处理我的 Rails 应用程序的身份验证，但从未真正理解它是如何工作的。因为 Devise 还使用 Rails 上设置的 session 存储配置，我假设这是一个关于 session handling with Rails.
的问题
基本上，我是一个授权新手。我读过一些关于身份验证的文章，但大多数都涉及抽象库（他们谈论引擎、中间件等），这些对我来说意义不大。我真的在寻找较低级别的详细信息。
这是我目前所知道的..
我知道 cookie 和 sessions。 Cookie 是存储在 client-side 上的字符串，用于在多个 HTTP 请求中维护 session。
以下是我对认证的基本理解（如有错误请指正）：
当用户登录时，我们向服务器发送SSL加密请求。如果凭据有效，我们会在数据库（或任何其他数据存储）上保存一个名为 session id 的随机字符串作为与用户 ID 关联的有效 session id。此 session id 会随着每个 login/logout 用户而变化。
在我们的数据存储中保存 session ID 后，我们 return 请求浏览器设置一个带有 session ID 的 cookie 的响应。这个 session id 连同用户 id 将被发送到域，直到它过期为止。对于每个请求，我们的服务器将检查 headers 上的 session id 并验证 session id 是否对该用户 id 有效。如果是，则认为该用户已通过身份验证。
这是我的问题：
我读过，默认情况下从 Rails 2 开始，它现在使用 CookieStore（而不是 SessionStore），它使用 SHA512（而不是 session ids)，所有这些都存储在一个 cookie 上，这意味着多个用户 id 可以从字面上具有相同的 session 哈希，并且它会正常工作。在我看来，这是一件非常危险的事情，使用存储在服务器上的单个密钥暴露大量哈希值，并将整个身份验证系统基于此密钥。是否存在使用散列而不存储服务器端 session id 的真实世界大型应用程序？
关于在服务器端存储活动 session id 的主题，我还读到您可以切换为 [=56 使用不同类型的 session 存储=].基于此，我听说系统将身份验证系统作为服务移出并使用身份验证令牌。什么是授权令牌，它与 session id 有何不同？
似乎我可以继续猜测一个随机字符串（用于哈希和服务器端 sessions）来获取现有的 session。有没有办法防止这种情况？使用存储在 cookie 上的更多值是否正常？ （例如用户名、真实姓名甚至用于身份验证的另一个哈希值）
我知道我问了很多，但我相信这对像我这样不了解身份验证的人很有用，对于打下坚实的主题基础非常有用。
I've read that by default starting from Rails 2, it now uses
CookieStore (instead of SessionStore) which generates session hashes
with SHA512 (instead of session ids), and all this is stored on a
cookie which means multiple user id's can literally have the same
session hash and it would just work fine. It seems to me that this is
a very dangerous thing, exposing a large number of hashes with a
single secret key stored on the server and basing your entire
authentication system based on this key.
是的，乍一看似乎很可怕，但我不确定真正的危险是什么。在 Rails 4 中，会话数据使用 PBKBF2 加密，然后使用您的会话密钥 签名。此签名有助于检测加密会话的内容是否已被篡改，如果检测到篡改，服务器将拒绝该会话。
https://cowbell-labs.com/2013-04-10-decrypt-rails-4-session.html
如果有人获得了会话令牌（用于签署会话 cookie）的访问权限，您手上的问题可能比最终用户试图冒充错误用户的问题要大得多。
Is there a real world large scale application that uses hashing
instead of storing server side session id's?
老实说，我不知道这个问题的答案，但我怀疑这是 Rails 的 "default" 这一事实意味着有很多网站那里使用 cookie 会话存储。
On the topic of storing active session id's on server side, I've also
read that you can switch to use different kinds of session storage for
Rails. Based on this, I've heard of systems moving authentication
systems out as services and using auth tokens instead. What's an auth
token and how does it differ from a session id?
我现在在服务器上执行此操作 - 基本上，当用户进行身份验证时会生成一个随机散列，然后将该散列存储、加密和签名在 cookie 中。 cookie 哈希是服务器端数据存储（在我的例子中是 Redis，但它可以在关系数据库或内存缓存或任何你喜欢的任何东西中）的密钥，实际会话数据是存储的服务器端映射到该密钥。这样一来，客户手中的会话数据就会减少，因为人们可能会对其进行解密和分析，因此通常会更安全一些。
Seems like I can just keep guessing a random string (for both hashing
and server side sessions) to grab an existing session. Is there a way
to protect against this? Is it normal to use more values stored on a
cookie? (such as the username, real name or even another hash for
authentication)
是的，你可以这样做，但这需要非常非常长的时间。您还需要猜测如何对新篡改的 cookie 数据进行签名，以便它与服务器期望在其端看到的内容相匹配，并且它是用一个非常大的密钥签名的。
我真的认为除了使用 cookies 之外，没有太多的持久身份验证状态的替代方法（我想 HTML5 本地存储可以工作，如果你有异国情调并且不太关心旧版浏览器的支持） .
我已经使用 Devise 一段时间来处理我的 Rails 应用程序的身份验证，但从未真正理解它是如何工作的。因为 Devise 还使用 Rails 上设置的 session 存储配置，我假设这是一个关于 session handling with Rails.
的问题基本上，我是一个授权新手。我读过一些关于身份验证的文章，但大多数都涉及抽象库（他们谈论引擎、中间件等），这些对我来说意义不大。我真的在寻找较低级别的详细信息。
这是我目前所知道的..
我知道 cookie 和 sessions。 Cookie 是存储在 client-side 上的字符串，用于在多个 HTTP 请求中维护 session。
以下是我对认证的基本理解（如有错误请指正）：
当用户登录时，我们向服务器发送SSL加密请求。如果凭据有效，我们会在数据库（或任何其他数据存储）上保存一个名为 session id 的随机字符串作为与用户 ID 关联的有效 session id。此 session id 会随着每个 login/logout 用户而变化。
在我们的数据存储中保存 session ID 后，我们 return 请求浏览器设置一个带有 session ID 的 cookie 的响应。这个 session id 连同用户 id 将被发送到域，直到它过期为止。对于每个请求，我们的服务器将检查 headers 上的 session id 并验证 session id 是否对该用户 id 有效。如果是，则认为该用户已通过身份验证。
这是我的问题：
我读过，默认情况下从 Rails 2 开始，它现在使用 CookieStore（而不是 SessionStore），它使用 SHA512（而不是 session ids)，所有这些都存储在一个 cookie 上，这意味着多个用户 id 可以从字面上具有相同的 session 哈希，并且它会正常工作。在我看来，这是一件非常危险的事情，使用存储在服务器上的单个密钥暴露大量哈希值，并将整个身份验证系统基于此密钥。是否存在使用散列而不存储服务器端 session id 的真实世界大型应用程序？
关于在服务器端存储活动 session id 的主题，我还读到您可以切换为 [=56 使用不同类型的 session 存储=].基于此，我听说系统将身份验证系统作为服务移出并使用身份验证令牌。什么是授权令牌，它与 session id 有何不同？
似乎我可以继续猜测一个随机字符串（用于哈希和服务器端 sessions）来获取现有的 session。有没有办法防止这种情况？使用存储在 cookie 上的更多值是否正常？ （例如用户名、真实姓名甚至用于身份验证的另一个哈希值）
我知道我问了很多，但我相信这对像我这样不了解身份验证的人很有用，对于打下坚实的主题基础非常有用。
I've read that by default starting from Rails 2, it now uses CookieStore (instead of SessionStore) which generates session hashes with SHA512 (instead of session ids), and all this is stored on a cookie which means multiple user id's can literally have the same session hash and it would just work fine. It seems to me that this is a very dangerous thing, exposing a large number of hashes with a single secret key stored on the server and basing your entire authentication system based on this key.
是的，乍一看似乎很可怕，但我不确定真正的危险是什么。在 Rails 4 中，会话数据使用 PBKBF2 加密，然后使用您的会话密钥 签名。此签名有助于检测加密会话的内容是否已被篡改，如果检测到篡改，服务器将拒绝该会话。
https://cowbell-labs.com/2013-04-10-decrypt-rails-4-session.html
如果有人获得了会话令牌（用于签署会话 cookie）的访问权限，您手上的问题可能比最终用户试图冒充错误用户的问题要大得多。
Is there a real world large scale application that uses hashing instead of storing server side session id's?
老实说，我不知道这个问题的答案，但我怀疑这是 Rails 的 "default" 这一事实意味着有很多网站那里使用 cookie 会话存储。
On the topic of storing active session id's on server side, I've also read that you can switch to use different kinds of session storage for Rails. Based on this, I've heard of systems moving authentication systems out as services and using auth tokens instead. What's an auth token and how does it differ from a session id?
我现在在服务器上执行此操作 - 基本上，当用户进行身份验证时会生成一个随机散列，然后将该散列存储、加密和签名在 cookie 中。 cookie 哈希是服务器端数据存储（在我的例子中是 Redis，但它可以在关系数据库或内存缓存或任何你喜欢的任何东西中）的密钥，实际会话数据是存储的服务器端映射到该密钥。这样一来，客户手中的会话数据就会减少，因为人们可能会对其进行解密和分析，因此通常会更安全一些。
Seems like I can just keep guessing a random string (for both hashing and server side sessions) to grab an existing session. Is there a way to protect against this? Is it normal to use more values stored on a cookie? (such as the username, real name or even another hash for authentication)
是的，你可以这样做，但这需要非常非常长的时间。您还需要猜测如何对新篡改的 cookie 数据进行签名，以便它与服务器期望在其端看到的内容相匹配，并且它是用一个非常大的密钥签名的。
我真的认为除了使用 cookies 之外，没有太多的持久身份验证状态的替代方法（我想 HTML5 本地存储可以工作，如果你有异国情调并且不太关心旧版浏览器的支持） .