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 对实现细节的理解是错误的，但他的论点是正确的。如果您希望使用成员(member) API，您必须从抽象类继承，因为 API 依赖于这些抽象类。 API 没有其他方法可以知道要使用的接口(interface)。

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

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

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

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