What are the pros and cons using the asp.net membership?_问答_开发者

I'm building a new website and a friend suggest to me to use the asp.net membership for the authentication process (login, 开发者_运维问答registration, password recovery, etc..).

I saw that everything is stored in an XML file.

I would like to know what are the pros and cons using the membership instead of to build something from scratch.

The MS login solution consists of several parts.

Authentication - "Who can access your site"

Forms Authentication - This basically creates a secure cookie that says "I'm authenticated!" on every request. Without this, users would have to log in every single page.

Pros: This works well
Cons: None - use it

Membership - This is how you store your users and their passwords, and validate user credentials. There are several ways to approach this:

Using the SqlMembershipProvider - Microsoft gives you a database to store users/passwords in securely, and gives you a way to authenticate credentials.
- Pros:
  - Less/no custom code to maintain. Works "out of the box"
  - Works with Membership controls and API
- Cons:
  - You have to use a Sql Server and use their database schema. (not a problem IMO)
  - No control over how passwords are initially generated. They're long and ugly
  - Steeper learning curve as you get familiar with the technology
Creating a custom MembershipProvider - You can inherit from MembershipProvider to customize where and how you store your data.
- Pros:
  - You get Encryption/Decryption of passwords for free
  - Control over where you store your users and what the data looks like
  - You can still use the Membership controls and API
- Cons:
  - Have to implement your own storage solution
  - You have to write, debug, and maintain a lot of custom code
  - If you add additional functionality, you have to cast the provider to use it
Creating your own Authentication scheme
- Pros: Complete control
- Cons:
  - You create everything, but have to debug/maintain everything.
  - You have to control security over credentials yourself.
  - Can't use Membership controls (This isn't a big loss as the controls are pretty simple to replicate)
  - Can't use Membership API

Authorization - "What can the users do?"

Roles - Roles control what the users can do via the authorization mechanism provided by the web.config and also works with security trimming on the sitemap.

Using the SqlRoleProvider - Microsoft gives you a database to store roles
- Pros:
  - Works with the web.config
  - You can assign more than one role to a user
- Cons:
  - Roles are just a string, no "hierarchy of permissions" support. This can make it difficult to create rules around which users can edit other users.
Creating a custom RoleProvider - You can inherit from RoleProvider to customize where and how you store your data.
- Pros: Works with the web.config
- Cons:
  - Have to implement your own storage solution
  - Still just a string and are as limited as the previous solution
  - If you don't implement it correctly, it could do a lot of database calls.
Creating your own Authentication scheme
- Pros: Complete control - Just do custom checks on your page and error/redirect as necessary
- Cons:
  - Doesn't work with the authorization mechanism provided by the web.config / sitemap. Practically this means that adding a page to a folder (such as /Admin) no longer guarantees security on that page.

It's important to note that the Membership and Role providers can be chosen or customized independently of each other. I would personally recommend using the SqlMembershipProvider if you can and evaluating your options for the Role Provider.

I dont like to use Membership Provider.

This is util when the scenario is "standard", but in cases that you need more custom rules, I think that dont works well. Appear "workarounds".

And not need store in a XML, exists another solutions (database, for exmaple).

Cons:

Your preferred datastore might not be fully supported out of the box
It might not match your current or future requirements
You might not fully understand the intricacies of how it works (over something you built yourself)

Pros:

You might save time compared to rolling your own.

Personally... if this is a serious project I would roll your own (but of course keep forms authentication). In my experience a lot of these 'out of the box' features from MS are rather half-assed.

The nice thing about ASP.Net Membership is that you can use as much or as little as you like - you can store user data in various forms (as others have mentioned), or you can just use ASP.Net Membership to handle session authorisation and page protection.

For example, you can go the whole hog and use the login control, the SQLMembershipProvider back end and just let ASP.Net Membership do everything end to end.

Or you can store your own usernames and passwords, in your own database table, authenticate the supplied details yourself and then simply just use "FormsAuthentication.RedirectFromLoginPage()" to tell ASP.Net membership that the user is authenticated, and have ASP.Net Membership then control access to pages.

ASP.Net Membership is tried and tested, its used by thousands of sites inside and outside of Microsoft, so you know the code works and works well. If there is an issue, then there are many implementations out there that will find it. Your own approach just has one user...

Actually, everything is not nessicarily stored in an XML-file. You can store the membershipdata in several ways, including a database.

You can also use the ASP.NET roles/membership library as a starting point for rolling your own. There are a few tutorials on doing this around the interwebs.

The pros with using the built-in functions is that the ASP.NET membership gui-controls more or less "just work".. ;)

In my opinion, the .NET membership providers are a great way to go regardless. I have written quite a few large applications using them. If your architecture is good, it's fairly simple to add functionality and change data in future releases.

Here's a bit of context to frame my answers. The membership/role/profile solutions in .NET consist of two parts: the framework and the providers. The framework consists of the methods and information your program will interact with. The providers determine how the data will be stored.

I find that the framework is excellent. There isn't much that you can't do regardless of how you want to interact with it. The default implementations do give you a lot for free. Any lack of functionality is further mitigated as a con if you are using good coding practices. See the starter ASP.NET MVC application for an excellent example of wrapping the membership framework.

The data never seems to work out the way you want, but it's nothing you can't work around. First as folks said, there are a bunch of providers shipped with .NET. And this is also where implementing your own provider comes into play. We usually start by subclassing SqlMembershipProvider. If something doesn't work the way we want, we override it. And changing the data tables at a later time if needed is not terribly difficult.

Using what already exists always seems to let us get going quickly and adapt as needed. In truth changes to this code don't happen often. Using the Microsoft solution at the beginning might not result with the prettiest piece of work, but it gets the job done quickly and lets you move on to solving important problems.