ASP.NET MVC中的角色缓存策略

Question

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

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

有没有人有替代路线？我知道在Session中缓存这些信息也不错？

Answer 1

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

我不同意Wyatt Barnett的评论：

  

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

缓存（无论是Session，ASP.NET Cache还是其他东西）都可以变化 - 只需要在需要时重新填充它。

回答你的问题：

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

2. 每次请求都会传输Cookie。因此，如果用户可以拥有大量角色，并且有可能超过浏览器支持的最大cookie大小，则可能会受到性能影响。

Answer 2

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

使用Session的缺点不在于会话存储非常违反且不是特别可靠的开销（最小）。例如，您可以轻松地丢失会话并仍然具有登录用户。

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

Answer 3

实际上，每次请求都会将cookie信息从浏览器发送到您的Web服务器，这就是Cookie的工作原理，但只要Cookie的大小合理，就不会对其产生太大影响。性能。如果您使用的是表单身份验证，我建议您按照this blog post中的说明将角色存储在表单身份验证Cookie中。在这种情况下，您只是将数据添加到已存在的cookie中。您应该知道，您可以在该Cookie中存储的数据量有一个上限，如here所述。