views:

1440

answers:

5

In a website, I need to integrate membership and authentication. So I want to use the functionality of ASP.NET Membership, but I have other custom stuff, that a "user" has to do.

So I am sitting here with my pencil and paper, drawing lines for my domain model... And how can I best utilize the ASP.Net membership, but extend it to fill my needs?

Should I create a class that inherits from a MembershipUser and extend it with my own properties and methods (and save this in a seperate table). Or should I let the MembershipUser be a property on my custom User/Client object?

What would be a good solid way to do this?

+3  A: 

I've extended MembershipUser and created my own version of the SqlMembershipProvider to map to my existing domain, and its working well, in production now.

MembershipUser is essentially a view over my User table. My extended MembershipUser class includes profile/account-style properties instead of using the default SqlProfileProvider system, which is a bit fragile.

I wasn't able to use the existing membership tables or sprocs, but wrote my own. For example, the SqlMembershipProvider uses a GUID as an opaque key, but the production system uses a plain old int. All of the dates are UTC, etc. too.

All of the extra User functionality is accessed via the User domain not via Membership methods.

HTH.

devstuff
+1 for having more patience than me!
Simon_Weaver
+7  A: 

I've thought about it and there are 2 ways that seem appropriate (of course there are more ways to make it work).

Custom Membership Provider

You change the membership provider to use your own and use your User object to store all the information.

The problem with this one is that it involves a lot of re-implementation of things that are already well handled by Asp.Net. The good thing is that you have a single User object with all the details.

Link from a Membership User to your User

With this method, you would use the original Membership provider to handle the user name and password, but you link your own User object with this one with something like the user name by using a service for example.

It's really easy to set up, you just need to create a service that would be used like this:

string userName = "Jon Skeet";
User user = new UserManagementServices().GetUserByUserName(userName);
GoodEnough
which way did you end up using? also how do you handle the situation where someone changes their username/email ? thats one of my biggest holes in my implementation right now
Simon_Weaver
I prefer the 2nd option, though I haven't used either that much. The username/email should never be the user identifier IMO, instead each user should have an identifier (number or guid) and the username/email should only be unique.
GoodEnough
+5  A: 

I ended up writing my own membership-provider, and have implemented that in 3 separate solutions now. It is extremely simple and much, much more elegant than linking a user to a membershipUser (which I have also tried).

Read this...:

Create Custom Membership Provider for ASP.NET Website Security

And if you want to learn more, watch this video (with sourcecode).

Kjensen
would you mind commenting on the impact of doing this as far as what you lose. do you lose any cookie tracking functionality, or admin console integration. not that the admin console is especially great but its something at least.
Simon_Weaver
I lose the admin console, which I never use anyway. And of course I lose all the functionality of the aspnet membership provider (changing password, storing stuff etc). But I am never implementing the aspnet membership provider again in anything I care about.I dont know what you mean by "lose cookie tracking functionality". I have not lost anything like that I am aware of. ;)
Kjensen
A: 

Hey guys, I've posted a detailed answer on writing your own Custom Membership Provider with your own existing database here... hope it helps! :-Dan

danfromisrael