我为什么要使用ASP.NET Membership安全模型？

我正在更新我的网站,并认为如果我要更新我的登录/安全模式,现在是个好时机.

我查看了ASP.NET中包含的Membership模型,但我不相信它会提供除了熟悉其他.NET开发人员之外的任何好处.

似乎有相当多的文档,但很少讨论为什么值得努力.

任何人都可以对此有所了解吗？

1> alchemical..：

---

我认为使用大型网站的会员资格几乎没有什么好处.这已作为ASP.Net身份验证的"解决方案"进行销售.然而,看起来微软似乎只是试图将旧的Membership Server产品定位为每个人突然需要的东西.

大约10年前,我在Msft的会员服务器上工作过.还是shop.microsoft.com上的首席开发人员,我可以告诉你我们在该网站上没有使用内部服务器产品 - 不是商业服务器,不是会员服务器.不知道他们现在是怎么做的 - 但我认为当时的普遍共识是这些类型的包装通常会妨碍我们试图做的事情.

它可能对较小的站点有用,或者如果您的资源有限......即部门或小型公司内部网的几百个用户,您不希望投入大量时间或资源.我看的越多,它对于更大的自定义网站来说就越不合适.

我真正不明白的是,几乎每一本ASP.Net书似乎都将这推动为唯一的方法,而不是一种方法.

---

编写自定义MP的努力似乎与编写完全自定义的解决方案大致相同.通过完全自定义,系统末端的代码总量将减少约20倍,可能减少50倍.

---

IMO,这是一个荒谬的比较.您可能会声称Membership Server与AD相同.MembershipProvider功能和Membership Server适用于完全不同的技术.MembershipProvider将扩展到db或AD store可以处理的任何内容.如果你达到了实际达到性能上限(不太可能)的程度,那就写下你自己的MP.

---

+1我真的没有得到它的固定.

2> Ian Mercer..：

---

在阅读了ASP.NET成员资格提供程序中的所有存储过程之后,我编写了自己的文档.这并不难,你在一天结束时有更多的控制权.

如果您喜欢XML配置,角色的弱类型字符串,默认情况下不安全,随机的web.config文件遍布您的目录,而不是页面类上的干净标记接口,表示"无需帐户",单个数据库命中登录,未从当前ObjectContext/DataContext加载的用户对象以及动态更改提供程序的能力(woo hoo,谁使用它？!)用于内置的.

如果没有,建立自己的,但如果你这样做,请确保存储密码的加密/盐渍哈希,并请做一个正确的加密cookie.

[更新以反映评论中的反馈]

---

要创建身份验证令牌:添加到期日期,Triple DES加密,然后使用URL安全字符进行Base64编码.使用URL安全Base64编码意味着您也可以在查询字符串上使用它们.我一直想在基于LINQ-to-EF的身份验证方案上写博客条目已经有一段时间......也许我现在就会付出努力.

3> Matt Peterso..：

---

除非你是唯一一个将在这个特定网站上工作的人,否则我认为.NET开发人员熟悉这一事实是进入内置会员路线的一个很好的理由.具有ASP.NET经验的其他开发人员可以快速进入项目并快速了解您站点的身份验证/授权模型.

我们在我们的网站上使用内置的成员资格和角色提供者模型,它运作良好......我们必须编写自己的Provider类,因为我们使用不同的数据后备存储(我们使用Microsoft Dynamics CRM),但是这些类非常简单且记录完备.通过预先完成这项工作,我们现在可以在代码中使用Membership和Roles类,以及在我们的页面上使用各种与登录相关的服务器控件.

你还在考虑另一种选择吗？