我们正在推出自己的身份验证提供程序，并将在HttpContext.Current.Session中执行典型的保持身份验证会话数据。我的问题是，那么我们是否还需要像客户端ID或sessionID一样持久保存客户端？
我正在考虑HttpContext何时死亡，就像我们回收应用程序池或服务器内存不足或我们明确清除HttpContext以便用户强制关闭会话。
我是否需要确保他们已经有一个我们也发送删除请求的cookie？
我试图理解为什么我们需要一个cookie来坚持会话。我的猜测是他们可以跳上另一台机器，使用相同的用户名和密码登录，现在我们在服务器上进行了2次会话！不对不对？所以你需要一个cookie来检查每次他们向我们的服务器请求的sessionID吗？如果不匹配，请删除其会话服务器端，发送删除cookie请求，并将其重定向回登录。或者，如果他们强行删除当前会话ID的浏览器cookie，我会看到它关闭了他们的HttpContext会话并将它们重定向到再次登录吗？
我正在推销自己的东西，而不是使用Forms Auth票。
当我们在内存中保存会话数据时，有人评论为什么我需要cookie吗？我们不想在我们搞砸我们的网址时使用cookieless，即使它被加密也不能安全地通过网址发送。
在这里工作的人说，如果我们使用它们，他们不想删除cookie，到期日期应该是60-90天。
我们正在使用MVC 3。
答案 0 :(得分：0)
想想你想在这里实现的目标：
如果用户关闭浏览器，他的会话通常会消失。如果他重新打开浏览器，他必须重新登录。会话也会在某个时刻自动过期。用户需要在此时重新登录。
有时这是好的。我的意思是有时候你想要那么对吗？
如果您正在构建的应用程序不是某些超级安全服务，那么您可以使用cookie来存储其中的一些用户详细信息。我存储用户的id并在将其与响应一起发送之前对其进行加密。每次我在请求中获取cookie时，我都会解密内容并自动登录用户。
这意味着用户始终登录，除非他清除cookie或明确注销。
考虑这一点：您可以在该cookie中存储每个小用户详细信息。只是存放他的身份或东西。但是如果你存储了他的id，那么你每次获得cookie时都需要加载User对象。这是每个请求所以它对你的数据库来说不是很好。在这种情况下，您可以将Session用作缓冲区。如果遇到此cookie，则会在会话中加载用户。在将来的请求中首先检查会话，然后检查cookie。这样，您基本上可以“缓存”会话中的用户详细信息，并且在注销时您必须清除cookie以及会话。
希望这有帮助。