自定义成员资格/角色/用户信息提供者无继承的MembershipProvider，RoleProvider等？ [英] Custom Membership/Role/Profile Providers WITHOUT inheriting the MembershipProvider, RoleProvider, etc.?

问题描述

有什么拖我从只是在做全体会员，角色和配置文件的自定义，无需从抽象类一样的MembershipProvider等继承？

Is there anything holding me back from just doing the whole membership, roles, and profiles custom, without inheriting from the abstract classes like MembershipProvider, etc.?

MSDN中明确指出：在实现自定义角色提供程序，您需要继承RoleProvider抽象类。 （的http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.aspx)

MSDN clearly states: "When implementing a custom role provider, you are required to inherit the RoleProvider abstract class." (http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.aspx)

不过，正如我在这里一起去，我发现我真的很定制整个事情到我们的具体需求，在很多情况下，我还没有实施什么继承，而是要我自己办法。我在做什么的一个例子是GetAllRoles的方法。 .NET要我实现返回一个字符串数组的方法。我觉得这不符合我的需求，在我们的情况下，角色中包含的不仅仅是一个名字更多的信息---我们有多种语言的角色的描述，例如。所以我去了，并提出所谓ProjectRole我自己的自定义类，搞得我GetAllRoles方法返回一个列表与LT; ProjectRole＆GT; 。然后presentation层上我可以提取每ProjectRole所有数据用一个简单的foreach循环。

However, as I'm going along here, I'm finding that I'm really customizing the whole thing to our specific needs, and in many cases, I'm not even implementing what's inherited, but instead going my own way. One example of what I'm doing is the "GetAllRoles" method. .NET wants me to implement a method that returns a string array. I find this doesn't meet my needs, as a "Role" in our case contains much more information than just a name --- we have descriptions of roles in multiple languages, for example. So I went and made my own custom class called ProjectRole, and made my GetAllRoles method return a List<ProjectRole>. And then on the presentation layer I can extract all the data from each ProjectRole with a simple foreach loop.

同样，我不希望返回的MembershipUser用户，而是ProjectUser在那里我可以提供我自己的领域。

Similarly, I don't want to return MembershipUser for users, but rather ProjectUser where I can supply my own fields.

到目前为止，一切工作正常。但是我还没有完成。我想知道的是，我在莫名其妙地拧自己，只是还没有意识到它吗？对于登录，我做

So far, everything is working fine. But I'm not finished yet. What I want to know is, am I somehow screwing myself and just haven't realized it yet? For logging in, I'm doing

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

如果我没有记错，我还没有使用任何方式的ASP.NET提供商在这一点上，除继承了一堆东西我最终会把 [过时] ，因为我剥离我自己的方法标签上。但是，我担心的是，到最后，我还是希望能够使用某些事情像 User.Identity.IsAuthenticated 和 User.Identity 。名称键，这样可以显示用户名一进去，就像欢迎+ User.Identity.Name 。难道这将是可能的，如果我走这条路呢？

If I'm not mistaken, I'm not even using the ASP.NET providers in any way at this point, other than to inherit a bunch of stuff I end up throwing [Obsolete] tags on because I spin off my own methods. However, what worries me is that in the end, I still want to be able to use certain things like User.Identity.IsAuthenticated and User.Identity.Name and such to display the user name once inside, like "Welcome " + User.Identity.Name. Is this going to be possible if I go down this route?

TL;博士 ---难道我不知何故无法正常使用，我继承了供应商拧自己，只是还没有意识到它尚未

tl;dr --- Am I somehow screwing myself by not properly using the Providers I'm inheriting from and just haven't realized it yet?

推荐答案

虽然Tim是错的实现的具体细节，他的论点是正确的。如果您想使用成员身份API您的必须的从抽象类继承，因为API依赖于这些抽象类。没有为API知道使用的接口没有别的办法。

Although Tim is wrong about the specifics of the implementations, his arguments are correct. If you wish to use the Membership API you MUST inherit from the abstract classes, because the API is dependant upon those abstract classes. There is no other way for the API to know the interface to use.

这并不意味着你必须使用成员身份API，但是。但是，正如蒂姆提到，你失去的成员，这是你可以在一个通用的供应商堵塞的最大好处之一，这是完全独立的应用程式。

That doesn't mean you have to use the Membership API, however. But, as Tim mentions, you lose one of the great benefits of Membership, which is that you can plug in a generic provider, and this is completely independent of your app.

这是 RoleProvider 有返回的字符串是为了让这些字符串可以针对对角色的标准声明（即用户进行比较的特定接口的原因。 IsInRole（）等。）这个内置的水管不知道你的扩展版本。如果你不执行标准版本，它会抛出异常，如果您尝试使用固有的功能。

The reason that RoleProvider has a specific interface that returns strings is so that those strings can be compared against standard declarations for roles (ie User.IsInRole(), etc..) This built-in plumbing knows nothing of your extended versions. And if you don't implement the standard versions, it will throw exceptions if you try to use inherent functionality.

有解决方案。成员，角色等。只是其他系统的实现特别的IPrincipal 和的IIdentity 。你可以完全绕过角色，成员资格，等等。如果你实现自己的这些接口的版本。然后，使用 User.IsInRole（）将调用的IPrincipal 的实施和 User.Identity。名称将会从您的自定义的IIdentity 实施返回数据。那么你已经下降了支持官方的成员资格和角色的API（有没有更低级别简介接口，配置文件只是隶属API的一部分）

There are solutions. Membership, Roles, etc.. are just implementations of other systems, particularly IPrincipal and IIdentity. You can completely bypass Roles, Membership, etc.. if you implement your own versions of these interfaces. Then using User.IsInRole() will call your IPrincipal implementation, and User.Identity.Name will return data from your custom IIdentity implementation. You have then dropped support for the official Membership and Role api's (there is no lower level Profile interface, Profile is just part of the membership api)

为什么要在乎这些？由于整个框架的安全基础设施是他们周围建造。如果你只是尝试使用会话变量做你自己的安全，你将有一个系统，是不安全的，容易断裂。

Why should you care about these? Because the frameworks entire security infrastructure is built around them. If you just try to do your own security using session variables, you will have a system that is insecure and prone to breakage.

这篇关于自定义成员资格/角色/用户信息提供者无继承的MembershipProvider，RoleProvider等？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！