我现在正在更新我的网站，并认为如果我要更新我的登录/安全模式，现在是个好时机。
我已经查看了ASP.NET中包含的Membership模型，但我不相信除了熟悉其他.NET开发人员之外它还会带来任何好处。
似乎有相当多的文档，但很少讨论为什么值得努力。
有人可以对此有所了解吗？
答案 0 :(得分：14)
我认为使用大型网站的会员资格几乎没有什么好处。这已作为ASP.Net身份验证的“解决方案”进行销售。但是，看起来微软似乎只是试图将旧的Membership Server产品定位为每个人突然需要的东西。
大约10年前，我在Msft工作过会员服务器。还是shop.microsoft.com上的首席开发人员，我可以告诉你我们在该网站上没有使用内部服务器产品 - 不是商业服务器，不是会员服务器。不确定他们现在是怎么做的 - 但我认为当时的普遍共识是这些类型的软件包通常会妨碍我们尝试做的事情。
对于较小的网站，或者如果您的资源有限，即部门或小型公司内部网的几百个用户，您不希望投入大量时间或资源，这可能很有用。我看的越多，它对于更大的自定义网站来说就越不合适。
我真正不明白的是，几乎每一本ASP.Net书籍都认为这是推动这项工作的唯一方法，而不是一种方法。
答案 1 :(得分：9)
在阅读了ASP.NET成员资格提供程序中的所有存储过程之后，我编写了自己的文档。这并不难，你在一天结束时有更多的控制权。
如果您喜欢XML配置，角色的弱类型字符串，默认情况下不安全，随机的web.config文件遍布您的目录，而不是页面类上的干净标记接口，表示“无需帐户”，多个数据库命中对于单个登录，未从当前ObjectContext / DataContext加载的用户对象以及动态更改提供程序的能力（woo hoo，谁使用它？！）用于内置的。
如果没有，请构建您自己的，但如果您这样做，请确保存储密码的加密/加盐哈希，并且请执行正确的加密cookie。
[已更新以反映评论中的反馈]
答案 2 :(得分：6)
除非你是唯一一个将在这个特定网站上工作的人，否则我认为.NET开发人员熟悉这一事实是进入内置会员路线的一个很好的理由。具有ASP.NET经验的其他开发人员可以快速进入项目并快速了解您站点的身份验证/授权模型。
我们在网站上使用内置的成员资格和角色提供者模型，它运作良好......我们必须编写自己的Provider类，因为我们使用不同的数据后备存储（我们使用Microsoft Dynamics CRM） ），但这些类非常简单，并且有详细记录。通过预先完成这项工作，我们现在可以在代码中使用Membership和Roles类，以及在我们的页面上使用各种与登录相关的服务器控件。
您还在考虑其他替代方案吗？
答案 3 :(得分：3)
我唯一不喜欢.Net附带的MembershipProvider的事实是userid是一个GUID而不是一个自动递增的身份。我知道使用GUID有奖金，但将其集成到预先存在的系统或模块中可能会很痛苦。
答案 4 :(得分：1)
只是为了让你不必自己动手。
答案 5 :(得分：0)
它的价值在于它是一个易于使用的现成基于角色的安全框架。如果您已经构建了自己的框架，并且迁移并非易事，那么它可能不值得。但是，迁移的一个好处是可以消除大量的应用程序代码并替换为框架代码。
答案 6 :(得分：0)
如果您想将您的网站迁移到任何类型的已经制作的门户软件 - 例如社区服务器或DotNetNuke，使用成员资格提供程序可以轻松迁移。您甚至可以使用现有数据库而不必实现新数据库。
答案 7 :(得分：0)
我认为ASP.NET成员资格，角色和配置文件的一个引人注目的功能是它使用提供者模型。如果你对它的方式不满意，那么从基类中推出你自己的并不困难。如果您查看codeplex.com，您可以找到人们编写的十几个或更多自定义提供程序。几年前我为SQLite数据库编写了一个。
答案 8 :(得分：0)
会员制路线运作良好但是有一个致命的缺陷，我不会因此而责怪微软。
Internet Explorer是唯一可以正确处理身份验证缓存的浏览器。
您可以关闭Firefox浏览器，打开它，然后恢复上一个会话，直接返回“安全”网站，无需登录.Chrome有类似问题，Mac也有同样的问题。
IE有一个正确处理此问题的javascript调用：document.execCommand（“ClearAuthenticationCache”，“false”）;
它不适用于任何其他浏览器。如果您使用此功能，则需要强制用户使用IE。