使用默认成员资格提供程序或继承它的自定义提供程序有什么原因？

Question

我在8个月前发布了这个问题.接受的答案涉及一些你不会通过默认提供商的规则播放而错过的东西.例如,如果您不使用从RoleProvider继承的自定义RoleProvider,则您将失去使用快速快捷方式的功能User.IsInRole().答案是指像"内置管道"这样的东西.

我想知道的是,我可以在哪里找到依赖于"内置管道"的完整列表,以及显示他们在幕后调用哪些重写方法的内容.

例如,HttpContext.Current.User.IsInRole()是(我假设)在我的自定义RoleProvider中引用并调用我的覆盖"IsUserInRole()"方法,但是我希望看到明确说明HttpContext.Current.User.IsInRole()实际调用的文档,IsUserInRole()对于所有提供者的所有此类方法.

我知道它应该是显而易见的(IsInRole()和IsUserInRole()是如此相似),但我的询问动机是看到并了解其他类型的可用的快捷方式,我甚至都不知道的.我有一种感觉,我已经多次重新发明了轮子,我甚至都不知道.

Answer 1

它们实际上并不相同，但无论您使用什么角色提供程序，都可能会填充当前用户的角色集合以包含提供程序的所有角色。

HttpContext.Current.User您可以IPrincipal在这里阅读：http://msdn.microsoft.com/en-us/library/system.security.principal.aspx

这是任何 .NET 应用程序（当然包括 ASP.NET）中的 Identity 的 .NET 约定。确保您正在使用的 IPrincipal 实现调用 RoleProvider 的相同函数的唯一方法是使用提供程序实际附带的函数。

角色提供程序根据 httpApplication 对象 ( http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx ) 进行实例化，并可供主体实现使用。

查看这篇 MSDN 文章的备注部分：http://msdn.microsoft.com/en-us/library/bb340078.aspxIsUserInRole主体对角色提供者的调用IsInRole完全取决于主体的实现提供者。