c# - 不继承 MembershipProvider、RoleProvider 等的自定义成员资格/角色/个人资料提供者？

Question

是否有什么阻碍我只自定义整个成员资格、角色和个人资料，而不继承抽象类(如 MembershipProvider 等)？

MSDN明确指出:“在实现自定义角色提供者时，需要继承RoleProvider抽象类。” ( http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.aspx )

然而，当我继续进行下去时，我发现我实际上是在根据我们的特定需求定制整个东西，而且在很多情况下，我什至没有实现继承的东西，而是我自己的方式。我正在做的事情之一就是“GetAllRoles”方法。 .NET 要我实现一个返回字符串数组的方法。我发现这不符合我的需求，因为在我们的案例中，“角色”包含的信息远不止名称——例如，我们有多种语言的角色描述。所以我创建了自己的名为 ProjectRole 的自定义类，并让我的 GetAllRoles 方法返回一个 List<ProjectRole>。 .然后在表示层上，我可以使用一个简单的 foreach 循环从每个 ProjectRole 中提取所有数据。

同样，我不想为用户返回 MembershipUser，而是返回 ProjectUser，我可以在其中提供自己的字段。

到目前为止，一切正常。但我还没有完成。我想知道的是，我是否以某种方式搞砸了自己，只是还没有意识到呢？对于登录，我正在做

if (ProjectMembershipProvider.ValidateUser(UsernameTextBox.Text, PasswordTextBox.Text == true)
{
   FormsAuthentication.SetAuthCookie(UsernameTextBox.Text, true);
}

如果我没记错的话，此时我什至没有以任何方式使用 ASP.NET 提供程序，除了继承一堆我最终抛出的东西 [Obsolete]标记是因为我分拆了自己的方法。然而，让我担心的是，最后，我仍然希望能够使用某些东西，比如 User.Identity.IsAuthenticated。和 User.Identity.Name这样就可以在里面显示用户名，比如 "Welcome " + User.Identity.Name .如果我沿着这条路走下去，这是否可能？

tl;dr --- 我是不是因为没有正确使用我继承自的提供程序而不知何故搞砸了自己，只是还没有意识到这一点？

Answer 1

尽管 Tim 在具体实现方面有误，但他的论点是正确的。如果您希望使用 Membership API，您必须继承抽象类，因为 API 依赖于那些抽象类。 API 没有其他方法可以知道要使用的接口(interface)。

但这并不意味着您必须使用 Membership API。但是，正如 Tim 提到的，您失去了成员(member)资格的一大好处，即您可以插入一个通用提供程序，而这完全独立于您的应用程序。

RoleProvider 具有返回字符串的特定接口(interface)的原因是这些字符串可以与角色的标准声明(即 User.IsInRole() 等)进行比较..) 这个内置管道对你的扩展版本一无所知。如果您不实现标准版本，当您尝试使用固有功能时它会抛出异常。

有解决办法。成员资格、角色等只是其他系统的实现，尤其是 IPrincipal 和 IIdentity。如果您实现自己的这些接口(interface)版本，您可以完全绕过角色、成员资格等。然后使用 User.IsInRole() 将调用您的 IPrincipal 实现，而 User.Identity.Name 将从您的自定义 IIdentity 返回数据 实现。然后，您放弃了对官方成员(member)资格和角色 api 的支持(没有较低级别的个人资料界面，个人资料只是成员(member)资格 api 的一部分)

为什么要关心这些？因为框架，整个安全基础设施都是围绕它们构建的。如果您只是尝试使用 session 变量来确保您自己的安全，您将拥有一个不安全且容易损坏的系统。