使用 asp.net 会员资格有哪些优点和缺点？
我正在构建一个新网站，一位朋友建议我使用 asp.net 会员资格进行身份验证过程（登录、注册、密码恢复等）。
我看到所有内容都存储在 XML 文件中。
我想知道使用会员资格而不是从头开始构建东西有什么优点和缺点。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
MS登录解决方案由几个部分组成。
身份验证 - “谁可以访问您的网站”
表单身份验证 - 这基本上会创建一个安全 cookie，上面写着“我已通过身份验证！”根据每一个要求。如果没有这个，用户将不得不登录每个页面。
会员资格 - 这是您存储用户及其密码以及验证用户凭据的方式。有几种方法可以解决此问题：
创建自定义 MembershipProvider - 您可以继承 MembershipProvider 来自定义存储数据的位置和方式。
创建您自己的身份验证方案
授权 - “用户可以做什么？”
角色 - 角色控制用户可以通过网络提供的授权机制执行哪些操作。配置并且还可以与站点地图上的安全修剪一起使用。
使用 SqlRoleProvider - Microsoft 为您提供一个数据库来存储角色
创建自定义 RoleProvider - 您可以继承 RoleProvider 来自定义存储数据的位置和方式。
创建您自己的身份验证方案
值得注意的是，成员资格和角色提供者可以相互独立地选择或定制。如果可以的话，我个人建议使用 SqlMembershipProvider 并评估角色提供程序的选项。
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.
Membership - This is how you store your users and their passwords, and validate user credentials. There are several ways to approach this:
Creating a custom MembershipProvider - You can inherit from MembershipProvider to customize where and how you store your data.
Creating your own Authentication scheme
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
Creating a custom RoleProvider - You can inherit from RoleProvider to customize where and how you store your data.
Creating your own Authentication scheme
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.
我不喜欢使用会员提供商。
当场景是“标准”时，这是有用的，但如果您需要更多自定义规则，我认为这效果不好。出现“解决方法”。
并且不需要存储在 XML 中，存在另一种解决方案（例如数据库）。
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:
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.
ASP.Net Membership 的好处是您可以根据需要使用任意数量的数据 - 您可以以各种形式存储用户数据（正如其他人提到的），或者您可以只使用 ASP.Net Membership 来处理会话授权和页面保护。
例如，您可以全力以赴并使用登录控件、SQLMembershipProvider 后端，并让 ASP.Net Membership 端到端地完成所有工作。
或者，您可以将自己的用户名和密码存储在自己的数据库表中，自己验证所提供的详细信息，然后只需使用“FormsAuthentication.RedirectFromLoginPage()”来告诉 ASP.Net 成员该用户已通过身份验证，并且拥有 ASP.Net然后，成员资格控制对页面的访问。
ASP.Net 会员资格经过尝试和测试，被 Microsoft 内外的数千个网站使用，因此您知道代码可以正常工作并且运行良好。如果存在问题，那么有许多实现可以找到它。你自己的方法只有一个用户......
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...
实际上，并非所有内容都必须存储在 XML 文件中。您可以通过多种方式存储成员资格数据，包括数据库。
您还可以使用 ASP.NET 角色/成员资格库作为您自己的角色/成员资格库的起点。互联网上有一些关于执行此操作的教程。
使用内置功能的优点是 ASP.NET 会员 gui 控件或多或少“正常工作”..;)
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".. ;)
在我看来，无论如何，.NET 会员提供商都是一个很好的选择。我已经使用它们编写了很多大型应用程序。如果您的架构良好，那么在未来版本中添加功能和更改数据将相当简单。
以下是一些背景信息来构建我的答案。 .NET 中的成员资格/角色/配置文件解决方案由两部分组成：框架和提供程序。该框架由您的程序将与之交互的方法和信息组成。提供商决定如何存储数据。
我发现这个框架非常好。无论您想如何与之交互，没有什么是您做不到的。默认实现确实免费为您提供了很多东西。如果您使用良好的编码实践，任何功能的缺乏都会进一步减轻。请参阅入门 ASP.NET MVC 应用程序，了解包装成员资格框架的优秀示例。
数据似乎永远不会按照您想要的方式工作，但没有什么是您无法解决的。首先，正如人们所说，.NET 附带了许多提供程序。这也是实施您自己的提供商发挥作用的地方。我们通常首先对 SqlMembershipProvider 进行子类化。如果某些东西没有按照我们想要的方式工作，我们会覆盖它。如果需要的话，稍后更改数据表也不是非常困难。
使用已经存在的东西似乎总是能让我们快速行动并根据需要进行调整。事实上，对该代码的更改并不经常发生。一开始使用 Microsoft 解决方案可能不会带来最漂亮的工作，但它可以快速完成工作，并让您继续解决重要问题。
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.