20

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?

Kjensen
  • 12,447
  • 36
  • 109
  • 171

4 Answers4

11

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);
mbillard
  • 38,386
  • 18
  • 74
  • 98
  • 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 Jan 07 '10 at 05:18
  • 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. – mbillard Jan 07 '10 at 14:06
7

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
  • 12,447
  • 36
  • 109
  • 171
  • 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 Jan 07 '10 at 05:17
  • 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 Jan 08 '10 at 18:27
3

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
  • 8,277
  • 1
  • 27
  • 33
0

I'm currently working through the Microsoft ASP.NET 2.0 Membership API Extended article from CoDe Magazine which explains how to extend the membership API by writing a wrapper around the existing classes. Main benefit is that you can keep all the out of the box functionality and not have to rewrite your own as you would when implementing a custom provider. Source code is provided.

Tone
  • 2,793
  • 6
  • 29
  • 42