8

我们有一个 ASP.NET MVC 应用程序，为此我们开发了我们自己的自定义 RoleProvider 类。如果没有缓存，它将访问每个请求的数据存储区 - 不好。我们可以找到的唯一缓存选项是（在 web.config 中）通过存储在客户端计算机上的 cookie。我的两个问题是：

  1. 这是否安全（即使启用了加密）？
  2. cookie 信息是否会随每个 Web 请求一起传输 - 因此，与每次访问数据存储相比，可能会降低应用程序的速度吗？

有人有替代路线吗？我知道在 Session 中缓存这些信息也很糟糕？

4

3 回答 3

6

如果您已经开发了自己的自定义 RoleProvider 类，您可以进行自己的数据缓存，例如使用 ASP.NET 缓存。这比使用 Session 作为缓存更灵活，因为它甚至可以在没有启用会话状态的页面上工作。

我不同意 Wyatt Barnett 的评论：

使用 Session 的缺点......事实上 Session 存储非常违反并且不是特别可靠

缓存（无论是 Session、ASP.NET 缓存还是其他东西）具有易失性是可以的——您只需要在需要时重新填充它。

要回答您的问题：

  1. 它与用于加密 cookie 的加密一样安全。如果您依赖 FormsAuthentication，它的安全性必须不亚于 Forms Authentication 票证。

  2. cookie 将随每个请求一起传输。因此，如果用户可以拥有非常多的角色，并且可能超过浏览器支持的最大 cookie 大小，则可能会影响性能。

于 2009-11-02T20:25:05.653 回答
2

虽然查询每个请求的数据库效率低下的想法是正确的，但请记住，现代数据库中正确索引表上的 SELECT 性能非常快，所以我首先要进行一些测量以确保这种情况实际上对性能产生负面影响，而不是理论上可能对日后的业绩产生负面影响。

使用 Session 的缺点与其说是开销（最小）不如说是 Session 存储非常违反并且不是特别可靠。例如，您很容易失去会话并仍然拥有登录用户。

也就是说，在这里解决中间问题的一个好方法是使用 HttpContext.Items 集合缓存每个请求的用户角色。这将限制每个请求一个 SELECT，这可能是相当有效的（参见上面的测量），同时避免了其他存储问题 - 例如胖、不安全的 cookie 或一些违反基于会话的解决方案。

于 2009-11-02T16:51:29.017 回答
2

实际上，cookie 信息会随着每个请求从浏览器发送到您的 Web 服务器，这就是 cookie 的工作方式，但只要 cookie 的大小合理，它就不会对性能产生太大影响。如果您使用表单身份验证，我建议将角色存储在表单身份验证 cookie 中，如本文所述。在这种情况下，您只是将数据添加到已经存在的 cookie 中。您应该知道，您可以存储在该 cookie 中的数据量有一个上限，如此处所述。

于 2009-11-02T20:12:29.423 回答