Question

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?

Was it helpful?

Solution

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);

OTHER TIPS

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).

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.

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top