仍然需要带有服务器端会话的 cookie 进行身份验证？

Question

我们正在推出我们自己的身份验证提供程序，并将在 HttpContext.Current.Session 中执行您的典型保留身份验证会话数据。我的问题是，那么我们还需要在客户端保留他们的 UserID 或 sessionID 之类的东西吗？

我正在尝试考虑 HttpContext 何时终止，例如我们回收应用程序池或服务器内存不足，或者我们显式清除 HttpContext 以供用户强制关闭会话。

我是否需要确保他们已经有一个我们也向其发送删除请求的 cookie？

我试图理解为什么我们需要一个 cookie 来保持会话。我的猜测是他们可以跳到另一台机器上，使用相同的用户名和密码登录，现在我们在服务器上进行了 2 个会话！不好对吧？所以每次他们向我们的服务器请求时，您都需要一个 cookie 来检查该 sessionID，对吗？如果不匹配，删除他们的会话服务器端，发送删除 cookie 请求，并将他们重定向回登录。或者，如果他们强制删除当前会话 ID 的浏览器 cookie，我会看到从而关闭他们的 HttpContext 会话并将他们重定向到再次登录，对吗？

我正在滚动自己的东西，而不是使用 Forms Auth 票证。

当我们将会话数据保存在内存中时，任何人都知道为什么我需要一个 cookie？而且我们不想在我们搞砸我们的 url 的地方使用 cookieless，即使它是加密的，通过 url 发送这些东西也不安全。

这里的工作人员说，如果我们使用 cookie，他们不想删除它们，到期日期应该是 60-90 天。

我们正在使用 MVC 3。

Answer 1

想想你想在这里实现什么：

如果用户关闭他的浏览器，他的会话通常会消失。如果他重新打开他的浏览器，他必须重新登录。会话也会在某个时候自动过期。用户此时需要重新登录。

有时这没关系。我的意思是有时你想要这样吗？

如果您正在构建的应用程序不是一些超级安全的服务，那么您可以使用 cookie 在其中存储一些用户详细信息。我存储用户的 id 并在将其与响应一起发送之前对其进行加密。每次我在请求中获得该 cookie 时，我都会解密内容并自动登录用户。

这意味着用户始终处于登录状态，除非他清除 cookie 或明确退出。

但请考虑一下：您可以在该 cookie 中存储每个小的用户详细信息。只需存储他的身份证或其他东西。但是如果您存储他的 id，那么您每次获取该 cookie 时都需要加载 User 对象。这是每一个请求，所以它对你的数据库来说不是很好。在这种情况下，您可以将 Session 用作缓冲区。如果您遇到此 cookie，请在会话中加载用户。在未来的请求中，首先检查会话，然后检查 cookie。这样，您基本上可以在会话中“缓存”用户详细信息，并且在注销时您必须清除 cookie 以及会话。

希望这会有所帮助。