2

在我之前的工作（ASP.NET webforms）中，我使用该HttpContext.Current.Session对象来保存当前用户会话的安全相关用户数据，例如

Session("userID") = 4525
Session("customerId") = 123
Session("importantValue") = "ABC"

在 WebAPI 2 上学了不少东西后，我现在开始学习 MVC。我一直在阅读Session和/或HttpContext.Current应该避免使用 MVC ......

  1. 同步和开销
  2. 会话污染 HTTP
  3. 应用程序冲突
  4. AppPool 回收

...但是简单的替代方案并没有很清楚。有人说使用TempData而其他人使用 cookie，但两者都有缺点。

我的应用程序是数据库密集型的，所以我想避免访问数据库来为每个请求重新读取这些值。在 WebAPI2 中有被序列化为 cookie 的不记名令牌。身份令牌是否足够安全以保存这些数据并避免用户篡改（如果通过 SSL 使用）？

4

1 回答 1

2

伙计，我不确定“使用TempData而不是会话”的想法来自哪里，但我真的很想追查源头并用钝器击中它们。TempData 是会话。它在后台使用会话存储。唯一的区别是，你放在那里的数据只能在下一个请求中存活，而放在里面的数据Session会一直存活到会话过期。否则，完全一样。

也就是说，围绕这个问题有很多争论，其中大部分是被误导的，只会导致进一步的混乱。然而，辩论的关键在于会议是非常糟糕的事情。但是，如果您需要添加状态概念，则确实没有其他选择。

看，HTTP 作为协议是无状态的。每个请求都是一个唯一的实体，不受之前或之后的任何其他请求的影响。Web API，因为你提到它，不使用会话，因为它是所谓的“符合 REST 的”，因为它遵循 REST 的准则。而且，本身以 HTTP 为模型的 REST 也是无状态的。然而，这毕竟是现实生活，你仍然需要做一些事情，比如验证请求。结果，诸如身份验证令牌之类的内容要么在请求查询字符串或正文中发送，要么通过 HTTP 标头发送。我认为这仍然是“会话”，因为传统会话的工作方式大致相同：您将一些“令牌”与请求、会话 ID 一起传递，服务器使用它来识别您是来自先前的请求。

所以，真的，当人们争论会话时，他们并不是在争论会话的概念本身，而是真正如何使用/滥用它，即使他们没有意识到这是他们在争论的内容。

我已经看到其他人争论使用 Redis 或其他 NoSQL 选项而不是会话的优点，但您只是在争论会话提供程序，而不是会话。

就个人而言，我认为Session在 MVC 项目中使用没有任何问题，只要你正确使用它。它非常适合为经过身份验证的用户创建状态。每次您想从站点请求新页面时都必须重新登录，这会很烦人。不过，除此之外，我几乎不理会它。实际上应该在多个请求中持久化的东西很少。

于 2014-08-27T15:11:45.707 回答