角色管理器是否缓存自定义角色提供程序的数据？我可以清除此缓存吗？
我正在使用自定义角色提供程序，它过度简化使用 .net 4 MVC 项目上的 EF 从数据库获取人员对象，并根据围绕该对象的一些规则（以及其他查询）分配用户角色。
数据会定期更改，尽管更改是通过系统中其他地方的代码而不是角色提供者进行的。角色提供程序是一种方法，它只是获取用户所在的角色。
当我更改数据库值时，角色管理器不会识别角色的更改，直到我重新编译（通过在 Web 配置中添加一个空格）示例），或者应用程序重新启动。
我通过设置 cacheRolesInCookie=false 确保角色不会缓存在 cookie 中，这也是大多数帮助似乎指出的内容，并假设角色管理器中内置了会话缓存。
我修改了返回 person 对象的 EF 查询，以包含时间戳作为查询的一部分。我可以通过探查器看到实际上正在调用查询，并且时间戳每次都会更改，但我的调试会话显示“人员”项目先前状态的陈旧数据。站点的其他部分显示“人员”表中的数据，其中显示了最新状态。
我真的不明白调试器应该如何处理缓存的数据。我不明白如果是缓存问题，为什么 EF 查询会触发，但人员数据肯定显示的是第一次运行时的状态，而不是表行的当前状态。
我觉得我错过了一些明显的东西。角色管理器是否缓存会话中的数据？
I'm using a custom role provider, which to over simplify gets a person object from the database using EF on .net 4 MVC project, and allocates user roles based on some rules around that (and other queries).
The data changes regularly, though changes are mode through code elsewhere in the system, not the roles provider. The roles provider is one way, and simply gets the roles a user is in.
When I change the database values, the role manager does not pick up on the change of roles until I do a recompile (by adding a space in web config for example), or the application otherwise restarts.
I've ensured the roles do not cache in a cookie by setting cacheRolesInCookie=false, which is what most help seems to point to, and presume there is a session cache built into the role manager.
I've modified the EF query which returns the person object to include a time stamp as part of the query. I can see through profiler the query is actually being called, and the time stamp changes each time, but my debug session shows stale data from the previous state for the 'person' item. There are other parts of the site that display data from the Person table, which show the up to date state.
I don't really understand how the debugger should behave on cached data. I don't see why the EF query would fire at all if it's a cache issue, but the person data is definitely showing state as per the first run, not as per the current state of the table row.
I feel I'm missing something obvious. Does the Role Manager cache data in session?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
答案实际上取决于您的应用程序的架构。我最近遇到了这个问题，并且也归咎于角色管理器缓存。事实证明，这完全是我的数据访问层中实体上下文的管理。我正在管理我的实体上下文并按照通常建议的方式存储每个请求的上下文。然而问题是，由于不相关的缺陷，上下文被设置了两次，因此角色提供程序的上下文始终与应用程序的其余部分不同，并且只设置了一次（因为角色提供程序是在应用程序启动时实例化的，而不是在应用程序启动时实例化的）。每个请求）。
我建议您查看如何存储数据上下文并进行跟踪，以了解与角色管理器和应用程序的其余部分相关的存储方式。确保您确实仅使用每个请求一个上下文。
The answer really depends on the architecture of your application. I had this problem recently and was blaming the Role Manager cache as well. Turns out it was the management of the Entity context in my Data Access Layer altogether. I was managing my Entity Context and storing the context per-request as is typically recommended. However the problem was that the context was being set twice due to an unrelated defect, and so the Role Provider's context was always different than the rest of the application, and was only set once (since the Role Provider is instantiated on Application Start, not per-request).
I'd recommend looking how you are storing data contexts and trace through to see how that is being stored in relation to your Role Manager vs the rest of the application. Ensure you are truly only using one context per request.
我有“我可以清除此缓存吗？”的答案。
是的，您可以清除角色管理器缓存。
（注意：此方法与删除角色缓存 cookie 不同，它允许您在请求期间清除缓存）。
在第一次调用角色提供程序以获取角色后，角色管理器将在 HttpContext.Current.User 中缓存当前用户的角色。
该缓存将在整个请求的后续角色检查中使用，并且您的自定义角色提供程序将不会被调用。
但是，您可以强制角色管理器再次调用您的角色提供程序（并有效地从数据源重新获取角色），方法是将当前用户强制转换为 RolePrincipal，然后调用 SetDirty()
例如：
请参阅 MS RolePrincipal.SetDirty 方法的文档
I have an answer for "Can I clear this cache?"
Yes, you can clear the Role Manager cache.
(note: this method is different from deleting the role cache cookie and allows you to clear the cache during a request).
The Role Manager will cache roles for the current user in HttpContext.Current.User after the first call to the role provider to get the roles.
That cache will be used in subsequent role checks throughout the request, and your custom role provider will not be called.
However, you can force the Role Manager to call your role provider again (and effectively re-grab the roles from the data source) by casting the current user to a RolePrincipal and then calling SetDirty()
For example:
See MS Documentation on RolePrincipal.SetDirty Method