ASP.NET Website Membership [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.

---

开发者_JAVA百科

Want to improve this question? Add details and clarify the problem by editing this post.

Closed last year.

Improve this question

We're hitting a good number of walls and stumbling blocks as we create our custom Membership based upon MembershipProvider, MembershipUser and RoleProvider etc.

We have a number of interesting requirements and Membership Provider doesn't appear to be helping us much in achieving them:

• Users may have multiple Logins.
• Users don't have a username directly (but may have a login that has a username).
• Users have one unique reference (currently an auto-incrementing primary key).

To implement this, we have two tables: Users which has a one-many relationship with Logins.

This effectively means we have a User who (in a hypothetical world) can log in via their Active Directory Account automatically (when possible) and via an OpenID or a Username/Password combination alternatively. We'll also have some users who may not have an AD account.

I had initially tried re-purposing the Membership classes by creating: - CustomMembershipProvider - CustomMembershipUser - CustomRolesProvider

But all my fighting against it has just given me black eyes and bruises, it really, really wants a username!

Have I gone about this the best way? Should I be starting from stratch and not inheriting anything? Should I be basing it on the IProvider class? Or maybe the GenericPrincipal and GenericIdentity classes? Or am I just plain missing something with MembershipProvider?

I want to keep the end programming experience as easy as it is for the out-of-the-box membership stuff, e.g.

Membership.GetCurrentUser();

And avoid a less than simplistic end-coder experience...

---

I had similar experience and decided to give all users a common Membership for role checking, etc and map it to differenct AuthenticationProviders (OpenID, AD, Membership Providers, etc) so they can be authenticated differently.