帮助我决定是使用ASP.NET默认成员资格/角色提供程序还是编写自定义提供程序

Question

I spent a good part of yesterday reading up on the subject and still feel like I am uncertain which way to go. I come from a "roll your own" background when it comes to authentication and authorization. We never used Forms authentication, let alone the Membership API. Looking at our old code we would use session variables to capture/control whether a user is logged in etc. With this new project I am about to undertake I want to put us back on track with what we should have done to begin with, which is use the tools provided by the framework.

I already have a database schema that I'll be working with, however it's not set in stone; I am able to make changes to it if necessary. In this schema there is already a Users table, utilizing an integer as the primary key. This table also has other information such as First and Last names. I also have foreign keys based on the UserId to other tables such as Phone and Address. Below I outline some of the pros/cons that come to mind.

Default Provider

Pros

• Less code.
• Ability to utilize all of the associated server controls such as Login, ChangePassword.

Cons

• Some controls might not be usedful to me out of the box. For example the CreateUserWizard, I will need to possibly capture other information during user creation such as phone and address information to associated tables. Not sure if this renders this control useless to me.
• I'll have to create foreign keys in my associated tables (Phone, Address) to the UserId which is a GUID in the default provider.
• If I do create these foreign key constrains and not utilize cascade delete; I will need to also delete associated rows in foreign key tables. Potentially having to utilize something like a TransactionScope object to make sure all of this is an atomic operation.

Custom Provider

Pros

• Ability to utilize existing schema tables.
• Easier to extract authentication/authorization into a service down the line.

Cons

• Have to provide implementation to most/everything myself.
• To use any of the controls, I'll have to provide their required implementation in the provider.

There might be other things I have not yet considered, being that I never used this before which makes me a little uncomfortable as well.

Thank you.

Answer 1

I recently had to make the same choice and decided to go with creating a custom provider.

My biggest reason to do this came down to the default db schema. All of the default db objects are created in the dbo schema and are prefixed with 'aspnet_' or 'vw_aspnet', etc. For me it was a real turnoff. If you haven't seen them yet, run aspnet_regsql.exe to create them.

In addition, Steven Sanderson says this in Pro ASP.NET MVC 2 Framework:

...SqlProfileProvider uses an especially disgusting database schema, in which profile entries are stored as colon-separated name/value pairs, so it's basically impossible to query.

Overall, it's worth following the API because of the clear separation of concerns, reuse across projects, and integration with the rest of ASP.NET, but you'll only want to use the built-in SQL storage providers for small or throwaway projects.

I haven't gone through the entire process of creating the custom providers yet (I did do a partial implementation when I was playing with Azure Table storage), but I plan to use these providers over multiple projects in the future, so I feel the effort will be well worth it.

Answer 2

If you are building a new application I would not hesitate to use the asp.net default provider. you can always decide not to use the default controls and programatically create your own. you can also save a lot of time by using any opensource pre created user management tool. At the same time you can always extend the information contained into the default tables.

Answer 3

Personally, I use the SqlMembershipProvider as a standalone entity while the rest of my database is in Oracle. I never look at the database, so the names and GUIDs don't bother me (out of sight, out of mind). It just works out of the box, which is great!

In my scenario, I've got a user table in the Oracle database that I insert/delete when membership users are created/deleted (no GUIDs). I consider the membership database to be the "master" record and the Oracle table to be there basically for referential integrity of supporting tables. It's not really done in an official transaction, but I use try/catch to keep them synchronized well enough.

The Role Provider is really limited and if you want any sort of hierarchical or dynamic roles, you're toasted. But it's a separate system completely isolated from membership and you don't have to use it.

The controls aren't bad. A lot of them support templates, so that you can add your own controls to them, and have plenty of events to hook into them. Don't be afraid to roll your own controls, but give the default controls a chance first. The ease of use of the Membership API really facilitate creating those controls.

Answer 4

Personally, I'd go with what the framework provides. There's no reason to roll your own authentication in this case.

In the past, you might have wanted to do things on your own, but nowadays there is no reason to.

I think if you tried to write this on your own, you'd be re-creating the wheel and it would take way too much time and resources to get it right. Especially, when dealing with security.