【问题标题】:Does the Roles Manager cache data for a custom roles provider, and can I clear this cache?角色管理器是否为自定义角色提供程序缓存数据,我可以清除此缓存吗?
【发布时间】:2011-10-14 04:54:41
【问题描述】:

我正在使用自定义角色提供程序,为了过度简化,它使用 .net 4 MVC 项目上的 EF 从数据库中获取人员对象,并根据一些规则(和其他查询)分配用户角色。

数据会定期更改,尽管更改是通过系统其他地方的代码而不是角色提供者进行的模式更改。角色提供者是一种方式,它只是获取用户所在的角色。

当我更改数据库值时,角色管理器在我重新编译(例如,通过在 Web 配置中添加空格)或应用程序重新启动之前不会接收到角色的更改。

我已通过设置cacheRolesInCookie=false 确保角色不会缓存在 cookie 中,这似乎是大多数帮助所指向的,并且假设角色管理器中内置了会话缓存。

我已经修改了返回 person 对象的 EF 查询,将时间戳作为查询的一部分。我可以通过探查器看到实际上正在调用查询,并且时间戳每次都会更改,但是我的调试会话显示“人员”项的先前状态的陈旧数据。站点的其他部分显示来自 Person 表的数据,这些数据显示最新状态。

我真的不明白调试器应该如何处理缓存的数据。如果是缓存问题,我不明白为什么 EF 查询会触发,但人员数据肯定显示的是第一次运行的状态,而不是表行的当前状态。

我觉得我遗漏了一些明显的东西。角色管理器是否缓存会话中的数据?

【问题讨论】:

  • 虽然我还没有弄清楚它是如何缓存的,但通过角色提供者设置角色似乎可以解决问题,而直接在其他地方调用代码则不会。我怀疑角色提供者有自己的数据上下文,这有点过时了。无论如何,我会通过角色提供者来解决这个问题。

标签: c# asp.net-mvc entity-framework security-roles


【解决方案1】:

答案实际上取决于您的应用程序的架构。我最近遇到了这个问题,并且也归咎于角色管理器缓存。原来这完全是我的数据访问层中实体上下文的管理。我正在管理我的实体上下文并按照通常推荐的方式存储每个请求的上下文。然而问题在于,由于不相关的缺陷,上下文被设置了两次,因此角色提供者的上下文总是与应用程序的其余部分不同,并且只设置了一次(因为角色提供者是在应用程序启动时实例化的,而不是每个请求)。

我建议您查看数据上下文的存储方式并进行跟踪,以了解与您的角色管理器和应用程序的其余部分相关的存储方式。确保您真正只使用one context per request

【讨论】:

  • 感谢您的反馈。我在这里采取了不同的方式,尽管您所描述的内容非常有帮助。我怀疑我在安全管理器对象中使用了上下文。如果这是由角色提供者在启动时实例化的,我怀疑过时的上下文卡在内存中。这就解释了为什么角色提供者只知道通过自己进行的更改。我仍然不了解分析器数据,但也许我可以通过将上下文转换为方法而不是类来解决问题。
【解决方案2】:

我对“我可以清除此缓存吗?”有一个答案

是的,您可以清除角色管理器缓存。

(注意:此方法与删除角色缓存cookie不同,允许您在请求期间清除缓存)。

第一次调用角色提供者获取角色后,角色管理器会将当前用户的角色缓存在 HttpContext.Current.User 中。

该缓存将用于整个请求中的后续角色检查,并且不会调用您的自定义角色提供程序。

但是,您可以通过将当前用户强制转换为 RolePrincipal 然后调用 SetDirty() 来强制角色管理器再次调用您的角色提供者(并有效地从数据源重新获取角色)

例如:

RolePrincipal currentUser = HttpContext.Current.User as RolePrincipal;
currentUser.SetDirty();

MS Documentation on RolePrincipal.SetDirty Method

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-02-17
    • 2011-04-03
    • 1970-01-01
    • 2014-07-16
    • 1970-01-01
    相关资源
    最近更新 更多