-1

我正在使用登录表单来验证用户身份。

FormsAuthentication是正确的，因为它将敏感的用户/角色成员身份存储在客户端的 cookie 或 URL 中。URL 中存在巨大的安全风险，因此我什至不会涉及。使用 FormsAuthenticationcookie，这会产生以下问题： a) 客户端处于指定其自己角色的位置的安全性；b) Cookie 中存储的数据过多。由于我没有通过安全获得任何收益，并且在用户数据存储的大小上浪费了大量时间，我宁愿只使用 Sessions。

我想FormsAuthentication为所有基本的登录表单处理功能重用类似的东西。但我宁愿让它将用户数据服务器端存储在 Session 中，而不是将客户端全部塞进一个 cookie 中。我宁愿只针对某种会话令牌进行身份验证。

我没有数据库，并且禁止本地磁盘存储用户数据。我依赖 3rd 方身份验证服务提供商，并且要求我必须减少与此服务的聊天。因此，用于临时存储用户信息的会话。糟透了，但这不一定是我要问的问题。此外，一个要求是我必须设置/使用 HttpContext.user 和可能的 Thread.CurrentPrincipal 以便稍后在 AuthorizeAttribute 等事情中使用，以便在视图中显示用户信息等。

因此，FormsAuthentication将所有用户数据客户端存储在 cookie 中。而 Session 将所有数据存储在服务器端，并且仅依赖于简单的客户端令牌 cookie。但是，在 asp.net 启动和身份验证步骤期间，Session 在任何地方都不可用。是否有等效形式的“成员资格”提供程序将所有数据存储在会话服务器端而不是客户端？

如果没有 Session 等价物...

  1. 我在哪里设置 HttpContext.user和Thread.CurrentPrincipal 以使这两个值在两个 MVC 应用程序的其余部分中都可用，而不会干扰或弄乱其他 MVC 组件？
  2. 取决于＃1，该入口点是否可以使用 Session ？如果没有，我如何使它可用，以便我可以使用存储在 Session 中的数据创建 Principle/Identity 对象？
  3. 这不可能是一个独特的要求。是否已经有库可以处理这个问题？
4

2 回答 2

1

会话也将信息存储在客户端 cookie 中！（如果没有 cookie，则在 URL 中）。

如果您想对客户端进行身份验证，他必须提供某种凭据——通常是他登录后 cookie 中的加密令牌。如果不是 cookie，那你有什么建议？

您应该使用 FormsAuthentication。存储在客户端 cookie 中的敏感信息使用只有 Web 服务器才知道的密钥进行加密。“加密方法是公共知识”并不意味着您可以在不访问适当的加密密钥的情况下解密数据。

您提到“角色”和“第三方身份验证提供者”。如果您的第三方也提供角色（即“授权提供者”和“身份验证提供者”），那么在服务器上缓存从提供者获得的角色是合理的。当请求被授权时，Session 是不可用的，所以最好的解决方案是使用缓存（System.Web.Caching.Cache）。

我个人会将其封装在自定义 RoleProvider中。自定义 RoleProvider 将GetRolesForUser通过在第一次调用时从第三方获取角色，然后将它们缓存在 Cache 中来实现。

于 2012-11-19T01:19:19.463 回答
0

不确定我是否喜欢我将要提出的建议，但您可以执行以下操作：

  • 利用应用程序状态或System.Cache作为用户凭据的全局存储。

  • 使用也可以加密的 InMemory 数据库（如 RavenDb）（我相信在内存中）。

    使用应用程序状态作为存储相对常见/频繁的东西的地方，我认为这不是一个好地方，因为

    • 缩放/锁定问题？<--只是一种直觉。
    • 永久数据？所以你在网站的内存中有用户......然后网站崩溃或回收等......现在这些数据会发生什么？
    • RavenDb 非常棒 - go.use.it.now。

我知道您没有在本地存储任何内容，因此每当用户访问您的系统时，您都需要刷新内存缓存等。很好。屁股疼，不过还好。（编辑：除非数据已缓存在内存中......也就是说）

总之，有两个建议。

专家提示：

哦！摆脱基于角色的 shiz 并开始使用基于声明的身份内容。是的，它仍然适用于 IPrincipal 和 HttpContext.User 等。所以之前的所有代码都没有被破坏。但现在它已融入 .NET 4.5

给你、我、每个人的精彩视频！

最后 - 奖金建议

在此处输入图像描述

一个很好的包，可以通过 Facebook/Google/Twitter 进行身份验证。您说您将用户信誉保留在另一个站点上（好举措！）。如果您使用其他提供商，请坚持使用 DNOA 或 SS。

GL！

于 2012-11-19T02:15:03.373 回答