views:

242

answers:

1

How would you handle membership in an ASP.NET MVC application? Using any external libraries? How would you do OpenID log in? username log in? email log in? any other that is worth looking into? Maybe all of them mixed into the application?

It seems ASP.NET comes with some pre-build user database (I'm totally new to .Net). The NerdDinner example uses it but then it makes the foreign keys use the username. That doesn't sound very good. Do you use this schema of two separate databases or only one? What do you use as the foreign key, any IDs?

I've found ASP.Net MVC Membership, anybody using it? does it work well? can it be expected to be maintained?

+3  A: 

Membership Providers are not new to ASP.Net MVC, they were introduced with ASP.Net 2.0. The Membership Provider model is simply an abstraction layer between your application and whatever source you are authenticating your users against. You can switch providers easily by simply changing your web.config file.

It is easy to write a membership provider, there are many walkthroughs on the web. Typically you would do so if you were using a database that used a different schema than the default examples that come with ASP.Net (which is most of the time). The foreign keys on the username thing in the NerdDinner example is a simplistic example that you would rarely see on any real-world databases.

I would highly recommend using the Membership model. Controls like the Login control are built to make use of it, and it is well-designed and makes it easy to change or combine different login methods for your application. If you want to use OpenID, a quick google search brought up this OpenID Membership Provider.

womp
Recommending the membership providers because of controls for an MVC app is, errr, not applicable, seeing as how server side controls are one of the things the MVC bits avoid like the plague.
blowdart
I disagree on "it is easy to write a membership provider". Providers are not easibly extensible. If you want to roll your own you have to overwrite all methods... and there are a lot. Anyway it is true that the Membershipsystem is a good choice for a lot of applications.
Malcolm Frexner
@blowdart - true, however MVC and ASP.Net are not mutually exclusive,and you should still leverage the membership providers.@Mathias - All you do is implement the interface. Since most applications only need the ValidateUser() function to log people in, and don't require user management - I find that the majority of the time you really only need to implement one of the functions.
womp
@Mathias Fritsch you only need to overwite the methods that you'll actually use.
Todd Smith

related questions