*不是*使用asp.net会员提供商是个坏主意吗？

Question

不使用内置的asp.net会员提供商通常是一个非常糟糕的主意吗？

我总是为我的asp.net应用程序(面向公众)推出自己的应用程序,并且确实没有遇到任何问题.它起作用,似乎避免了一层复杂性.我的需求非常基本:一旦设置,用户必须使用电子邮件地址和密码登录,如果忘记了,它将通过电子邮件发回给他们(一个新的).设置完成后,每个用户帐户都需要做很少的工作,但我需要为每个用户存储几个额外的字段(全名,电话和其他一些字段等).需要登录凭据的用户数量很少(通常只是管理员和一些备份),其他所有人都使用未经身份验证的站点.

通过跳过asp.net会员提供程序功能,我可能错过了哪些大优势？

Answer 1

滚动自己的身份验证系统绝不是一个好主意.有很多方法可以解决这个问题似乎仍在测试中,直到一年后你发现你的网站在六个月前被破解了.

始终尽可能地利用您的平台为您提供的安全代码,无论是asp.net还是其他任何东西.这样做,系统由具有更多部署的供应商提供支持,以便更容易找到并修复错误,即使您遇到问题,也可以在老板提出问题时将责任归咎于供应商.更不用说一旦您第一次使用供应商的解决方案,其他部署将更快.这是正确的方法.

ASP.Net会员提供商远非完美,但我向您保证,最好从头开始构建它.

Answer 2

这里概述了提供者模型的优点,但简而言之:

1. 某些开箱即用的Web控件是为了使用成员资格提供程序模型而构建的,例如Login控件/视图和Create User Wizard.因此,如果没有编写任何代码,您将错过一步配置,即拥有所有页面的登录仪表板.

2. 可以通过web.config文件中的简单更改来交换提供程序.并不是说你不能写自己的登录资料来做同样的事情,但你可以在不久的将来编写自定义提供程序并将其切换到应用程序而无需更改应用程序中的内容.

3. 提供所有基础知识.默认成员资格提供程序具有密码检索,帐户锁定,多种密码加密方法,有效的密码限制规则配置和用户管理,所有这些都是开箱即用的.仅仅使用它就可以大大减少大多数人从头开始创建ASP.Net应用程序的设置时间.

4. 您的应用程序的一个重要组件已经过审查.您无需担心调试所有自己的身份验证代码!这意味着当存在错误时,您经常在站点中断之前获得修复,并且如果没有,您就有能力通过错误.

Answer 3

我同意Ayende对此的感受:

它是一个巨大的API,它做了很多假设,从它给你的东西和你必须实现的东西来看,它真的不好用

这也是我的经验.任何时候我都实现了自己的成员资格提供者(在撰写本文时两次)我将绝大多数被覆盖的方法都未实现,因为我永远不会打电话给他们而我没有使用任何网络表单使用它们的控件.

如果Sql和Active Directory提供商满足您的所有需求,那么它们就非常棒.但如果他们不这样做,并且您正在考虑实施提供商,那么可能有更好的方法.

不要将MembershipProvider与FormsAuthentication混淆,我仍然经常依赖FormsAuthentication来处理我的应用程序.这是一种机制,负责将用户的身份验证令牌包装在cookie中并在客户端和服务器之间传递.据我所知,FormsAuthentication没有任何问题,我不建议重新发明它.

如果您不想实现许多MembershipProvider方法,RoleProviderMethods和ProfileProvider方法,那么只需实现IPrincipal和IIdentity,然后执行您需要执行的操作.这是一个让这两个接口使用FormsAuthentication 的例子,这很简单.

此外,请注意,您需要聪明地存储用户的凭据.该SqlMembershipProvider的做至少可以储存哈希盐渍密码.确保你至少做同样的事情.这是一段很好的代码来帮助解决这个问题.请注意使用的慢哈希算法.不要吸毒.

更新(2013-12-16)

自从我写这篇文章以来,ASP.net的情况发生了变化.ASP.NET Identity取代之前的Membership功能.

我的建议是使用新的东西,因为:

• 您可以实现各种接口以组成满足您需求的解决方案.这意味着您可以实现所需的部件,并忽略您不需要的部件.
• 您可以完全更改存储身份数据的位置/方式,同时保留控制密码如何散列的默认实现.
• OAuth和OpenID功能.
• 您可以在基于OWIN构建的任何框架中使用相同的系统.

API比以前稍微复杂一些,但更灵活.