c# - 使用默认成员资格提供程序或继承它的自定义成员资格提供程序的幕后积极原因是什么？

Question

我发布了 this 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)中身份的 .NET 约定。您可以确定您正在使用的 IPrincipal 的实现是调用您的 RoleProvider 的相同功能的唯一方法是使用您的提供者实际附带的功能。

角色提供者是根据 httpApplication 对象 ( http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx ) 实例化的，可供 Principal 实现使用。

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