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