使用asp.net会员资格有哪些优缺点？

我正在建立一个新网站，朋友建议我使用asp.net会员资格进行身份validation过程（登录，注册，密码恢复等）。

我看到所有内容都存储在XML文件中。

我想知道使用成员资格的优缺点，而不是从头开始构建一些东西。

Answer 1

MS登录解决方案由几个部分组成。

身份validation – “谁可以访问您的网站”

表单身份validation – 这基本上创建了一个安全的cookie，上面写着“我已经过身份validation！” 在每个请求。 没有这个，用户就必须登录每一页。

• 优点：这很好用
• 缺点：无 – 使用它

成员资格 – 这是您存储用户及其密码以及validation用户凭据的方式。 有几种方法可以解决这个问题：

1. 使用SqlMembershipProvider – Microsoft为您提供了一个安全地存储用户/密码的数据库，并为您提供了一种validation凭据的方法。
   • 优点：
     • 更少/无需维护的自定义代码。 作品“开箱即用”
     • 使用成员资格控制和API
   • 缺点：
     • 您必须使用Sql Server并使用其数据库架构。 （不是问题IMO）
     • 无法控制最初生成密码的方式。 他们漫长而丑陋
     • 熟悉该技术后，学习曲线更加陡峭

2. 创建自定义MembershipProvider – 您可以从MembershipProviderinheritance以自定义存储数据的位置和方式。

   • 优点：
     • 您可以免费获得密码的加密/解密
     • 控制存储用户的位置以及数据的外观
     • 您仍然可以使用Membership控件和API
   • 缺点：
     • 必须实施自己的存储解决方案
     • 您必须编写，调试和维护大量自定义代码
     • 如果添加其他function，则必须强制使用提供程序

3. 创建自己的身份validation方案

   • 优点：完全控制
   • 缺点：
     • 你创建了一切，但必须调试/维护一切。
     • 您必须自己控制凭据的安全性。
     • 无法使用成员控制（这不是一个很大的损失，因为控件很容易复制）
     • 无法使用Membership API

授权 – “用户可以做什么？”

角色 – 角色通过web.config提供的授权机制控制用户可以执行的操作，并且还可以在站点地图上进行安全修整。

1. 使用SqlRoleProvider – Microsoft为您提供了一个存储角色的数据库

   • 优点：
     • 适用于web.config
     • 您可以为用户分配多个角色
   • 缺点：
     • 角色只是一个字符串，没有“权限层次结构”支持。 这可能使创建用户可以编辑其他用户的规则变得困难。

2. 创建自定义RoleProvider – 您可以从RoleProviderinheritance以自定义数据的存储位置和方式。

   • 优点：适用于web.config
   • 缺点：
     • 必须实施自己的存储解决方案
     • 仍然只是一个字符串，并且与之前的解决方案一样有限
     • 如果没有正确实现它，它可以执行大量的数据库调用。

3. 创建自己的身份validation方案

   • 优点：完全控制 – 只需对您的页面进行自定义检查，并根据需要进行错误/重定向
   • 缺点：
     • 不适用于web.config / sitemap提供的授权机制。 实际上，这意味着将页面添加到文件夹（例如/ Admin）不再保证该页面的安全性。

---

值得注意的是，可以相互独立地选择或定制成员资格和角色提供者。 我个人建议使用SqlMembershipProvider，如果可以，并评估您的角色提供程序的选项。

Answer 2

我不喜欢使用会员提供商。

当场景是“标准”时，这是util，但是如果你需要更多自定义规则，我认为这样做不太好。 出现“变通办法”。

并且不需要存储在XML中，存在另一种解决方案（数据库，例如）。

Answer 3

缺点：

• 您的首选数据存储可能不是完全支持开箱即用的

• 它可能与您当前或未来的要求不符

• 你可能不完全理解它的工作原理的复杂性（你自己构建的东西）

优点：

• 与滚动自己相比，您可以节省时间。

就个人而言……如果这是一个严肃的项目，我会自己动手（但当然要保持表格认证）。 根据我的经验，MS的这些“开箱即用”function相当一半。

Answer 4

ASP.Net Membership的好处在于你可以随意使用多少 – 你可以以各种forms存储用户数据（正如其他人提到的那样），或者你只需​​使用ASP.Net Membership来处理会话授权和页面保护。

例如，您可以使用登录控件，SQLMembershipProvider后端，让ASP.Net Membership完成所有端到端的操作。

或者您可以在自己的数据库表中存储自己的用户名和密码，自己validation提供的详细信息，然后只需使用“FormsAuthentication.RedirectFromLoginPage（）”告诉ASP.Net成员用户已经过身份validation，并拥有ASP.Net然后，成员控制对页面的访问。

ASP.Net会员资格经过试用和测试，被微软内部和外部的数千个网站使用，因此您知道代码可以正常运行。 如果存在问题，那么有很多实现可以找到它。 你自己的方法只有一个用户……

Answer 5

实际上，一切都不会被遗忘地存储在XML文件中。 您可以通过多种方式存储membershipdata，包括数据库。

您还可以使用ASP.NET角色/成员资格库作为滚动自己的角色/成员资格库的起点。 关于互联网，有一些关于这样做的教程。

使用内置函数的专业人员是ASP.NET成员资格gui控制或多或少“正常工作”..;）

Answer 6

在我看来，.NET会员提供商是一个很好的方式。 我已经写了很多使用它们的大型应用程序。 如果您的架构很好，那么在将来的版本中添加function和更改数据相当简单。

这里有一些背景来构建我的答案。 .NET中的成员资格/角色/配置文件解决方案由两部分组成：框架和提供程序。 该框架包含您的程序将与之交互的方法和信息。 提供者确定如何存储数据。

我发现框架非常好。 无论你想如何与它互动，你都无法做到。 默认实现确实为您提供了大量免费。 如果您使用良好的编码实践，任何缺乏function都会进一步减轻。 请参阅入门ASP.NET MVC应用程序，以获取包装成员资格框架的绝佳示例。

数据似乎永远不会按照你想要的方式运行，但是你无法解决这些问题。 首先，正如人们所说，.NET附带了许多供应商。 这也是实施您自己的提供商的地方。 我们通常从子类化SqlMembershipProvider开始。 如果某些东西不能按我们想要的方式工作，我们会覆盖它。 如果需要，稍后更改数据表并不是非常困难。

使用已经存在的东西似乎总是让我们快速前进并根据需要进行调整。 实际上，对此代码的更改不会经常发生。 在开始时使用Microsoft解决方案可能不会产生最漂亮的工作，但它可以快速完成工作并让您继续解决重要问题。