不管是什么语言和框架，这在低级别中是如何工作的——将一个变量放入会话中以验证用户身份？
put_session(curr_connection, :current_user, user.id)
用户用户是否保存在 cookie 中？在客户端？那么是什么阻止浏览器用户通过存储他们想要的任何用户的 id 并代表该用户进行身份验证来更改它呢？或者user.id 是否保存在服务器上，而在客户端我们只有一个很长的 会话 ID，在 cookie 或 url 中？
【问题讨论】：
简短的回答是视情况而定。所有语言/框架都有其默认值，例如 Ruby on Rails 默认将其存储在 cookie 中，PHP 将其存储在服务器上等。但是在几乎所有这些语言中，您都可以将 cookie 存储更改为您想要的任何内容。
一些选项（可能还有更多）：
Cookies - 在这种情况下，cookie 在发送到客户端之前被加密。用于加密的密钥是某种应用程序设置。这有点安全，因为即使会话值存储在客户端上，用户仍然无法查看或修改它们，因为他没有应用程序密钥。这样做的好处是非常简单并且需要零设置，缺点包括这比其他解决方案更不安全，而且可以存储在 cookie 中的数据量是有限的。
服务器内存 - 在这种情况下，将加密随机会话 ID 发送到客户端，所有会话数据都存储在应用程序服务器内存中，由会话 ID 标识。优点是它不会写入磁盘，也不会发送到客户端。缺点是应用服务器重启时会话数据丢失。
服务器文件系统 - 传统方法（某种），会话数据存储在文件中，以便在应用程序服务器重新启动时保持不变。在这种情况下，对这些文件的访问控制是关键，但通常由语言或框架负责。
服务器 SQL 数据库 - 传统的重量级方法，所有会话数据都存储在应用程序服务器或单独数据库服务器上的关系数据库中。优点是您可以直接控制任何用户的会话内容，而不仅仅是登录的用户（例如，通过从数据库中删除会话条目很容易为管理员强制注销）。在应用程序级攻击的情况下，同样的事情也可能是一个缺点。运营成本也更高。
服务器 NoSQL 数据库 - 与关系数据库大致相同，但也可以使用 Redis 等非关系数据库。一个缺点可能是 Redis 中的访问控制至少可以说不是很强大。
会话服务 - 在某些企业应用程序中，您可能希望实现某种会话服务（RESTful 或其他）。显然，这只是将问题推后一层，会话数据仍必须使用上述选项之一存储在某个地方。
您的语言或环境可能已经支持其中的一些，如果您想要开箱即用不支持的语言或环境，您可以实现自己的。但是，会话管理是一项棘手的业务，很容易使其易受攻击。 OWASP 有一个很好的session management cheat sheet 可以咨询。
【讨论】：