What are the disadvantages of using/writting a .Net Custom Membership Provider?

Question

Recently, I posted the following question on SO: https://stackoverflow.com/questions/7197337/using-asp-net-membership-provider-with-an-existing-user-database

As you may notice, I ended up answering my own question stating that it looked like writting/implementing a "Custom Membership Provider" was the way to go.

Literally, a few minutes later, I stumble across this question: https://stackoverflow.com/questions/7222306/simple-login-attempt-counter-using-mvc-3-and-ajax/7222407#7222407

I try to answer and get a comment back that .Net Membership provider is "terrible on many levels". I'll admit, this is the first time I'm using Membership provider but it sure looked slick to me.

I haven't seen anything that backs up the "terrible" claim so before I implement something "terrible", I was hoping to get some feedback from the community.

Answer 1

So I'm not sure "terrible" is the best word here. However, it has limitations, and as soon as your needs do not fit how the membership provider was designed you end up with a lot of glue code. If you can use the membership provider out of the box, I would say go for it. As soon as you start writing a custom one I question using the membership stuff anyways.

In my experience the membership provider buys you...

• Sign up already built in for MVC app
• Account editing
• Forgot Password is easy to hook up
• Validate user method

I'm sure there's something else I'm missing but I think those are the big ones. Now when you need custom password management, two factor authentication, to work with an existing data model, or a whole host of other things you start to lose out. The code that's already written for you with the membership provide should take on the order of a few days to duplicate if you know what you're doing.

Answer 2

It doesn't do what you want. At first glance you may find it takes care of all your needs and some, but a new requirement comes up. Now you 'really' have to learn how this thing works. The benefit of having all of this prebuilt diminishes because you were in that false sense of security.

@Travis mentioned using an existing data model, but the choice of database can be a restriction as well: Oracle?

I don't know if it works with 3rd party verification systems like Facebook or Google.

Answer 3

They aren't as flexible as many people think on a quick read of the docs, but they have their place.

If you don't need control over the user tokens and only need to build a custom/extended user data or membership set or need to pull that data from a existing/different source they have their place.

If you want to alter more than that you are often better off replacing the httpmodule that runs one of the auth providers then you get all the control. Most people I have encountered breaking things with providers made the wrong choice for their situation at this level.

Either way you get a properly populated context.user which allows you to continue using most asp.net based user functions.

Answer 4

This question is old but I'm getting badges for it's popularity so I figure it's worth it to provide an updated answer.

Microsoft's "Simple" Membership provider finally got it right in my humble opinion. If you are writting something new or even attaching to a legacy database with a new application. Use the simple membership provider. WAY EASIER and CLEANER to implement. Install a couple of tables and point the provider to your list of users and you are basically done.

This link will get you started or just google it: http://www.mattjcowan.com/funcoding/2012/11/10/simplemembershipprovider-in-mvc4-for-mysql-oracle-and-more-with-llblgen/