在我以前的工作（ASP.NET webforms）中，我使用了HttpContext.Current.Session对象来保存当前用户会话的安全相关用户数据，例如，webforms会话值现在应该存储在MVC承载令牌中吗？
Session("userID") = 4525
Session("customerId") = 123
Session("importantValue") = "ABC"
在WebAPI 2上学到了很多东西，我现在开始学习MVC。我不断地读取Session和/或HttpContext.Current应与MVC避免...
...但有没有一个很多简单的选择清晰。有些人说使用TempData而其他的cookie，但也都有缺点。
我的应用程序数据库很大，所以我想避免触击数据库来重新读取每个请求的这些值。在WebAPI2中，有持久性令牌被序列化为cookie。身份标识足够安全以保存这些数据并避免用户篡改（如果通过SSL使用）？
男人，我不确定在哪里“使用TempData而不是会话”的想法来了，但我真的很想追踪消息来源并用钝器击中它们。 TempData是会话。它在引擎盖下使用会话存储。唯一的区别是你放在那里的数据只能存在于下一个请求中，而放置在Session中的数据会一直存在直到会话过期。否则，这是完全一样的东西。
这就是说，围绕这个问题存在很多争议，其中很多都是误导，导致更多的混淆。然而，辩论的关键是会议是非常糟糕的事情。但是，如果你需要添加一个状态的概念，那么真的没有其他选择。
请参阅HTTP作为协议是无状态。每个请求都是一个独特的实体，不受任何其他请求之前或之后的影响。 Web API，因为你提到它，不会使用会话，因为它是所谓的“REST兼容”，因为它遵循REST的指导原则。而且，本身是在HTTP之后建模的REST也是无状态的。然而，毕竟，这是真实的生活，你仍然需要做一些事情，比如验证请求。因此，诸如身份验证令牌之类的内容可以通过请求查询字符串或正文或通过HTTP标头发送。我认为这仍然是“会话”，因为传统会话的工作原理与此类似：您将请求，会话ID和服务器用于识别您作为同一客户端的某个“令牌”以前的请求。
所以，当人们争论会议时，他们并没有太在意会话的概念本身，而是真的如何使用/滥用，即使他们没有意识到这是他们'重新争论。
我见过其他人认为使用类似Redis或其他NoSQL选项而不是会话的优点，但在那里你只是在讨论有关会话提供程序，而不是会话。
就我个人而言，在MVC项目中使用Session没有什么问题，只要您正确使用它。为认证用户等事情创建状态非常好。这将是很恼人的，每次你想要从一个网站申请一个新的页面时，必须再次登录。不过，除此之外，我几乎不管它。实际上应该跨多个请求持续存在的事情非常少。
这是一个很好的答案，谢谢。触及你的最后一点，除了“User.Identity.Name”或“角色”以外，'Session'中应该有什么类型的东西*？我猜基于cookie的身份验证令牌足够强大，可以存储在客户端设备上，而不必担心被黑客入侵（我认为ASP.NET cookie受AES保护，然后只通过SSL提供）？ – EvilDr 2014-08-27 16:09:39
我个人使用的一个例子是在电子商务环境中存储“促销”代码。如果用户来自带有促销代码的链接，我将其保存到会话中，以便在结账时应用。我真的不能想到许多其他例子，我明确地使用了'Session'（除了通过认证的隐式使用），它应该告诉你一些关于它的使用应该是多么罕见的事情。 – 2014-08-27 18:00:01
这不是一个简单的问题，由于开发人员的多样化“味道”。如果你知道你在做什么，使用'Session'对象没有什么坏处。 – 2014-08-27 13:38:48
请链接到声称你不应该使用会话的来源。应该有考虑，但从不说永远。如果上述消息来源没有激发你不应该使用该会话的原因，请不要继续阅读它们。在某些情况下，为什么不应该使用会话有完全有效的原因，但是由您来评估这些情况是否适用于您。 – CodeCaster 2014-08-27 13:41:46
反复听到的原因是“会话劫持”。但通过一些调整，这可以完全消除。另一个是你需要存储的数据量。你有数百兆的数据，那么使用现有的缓存机制可能会更好。 – 2014-08-27 13:43:25