使用asp.net成员资格提供程序不是一个坏主意吗?

使用自己的身份验证系统 好主意。有太多的方法让它出错 似乎

总是 尽可能地依赖于您的平台为您提供的安全代码,无论是asp.net还是其他任何东西。这样做,系统就会得到部署更多的供应商的支持,这样就可以更容易地发现和修复错误,即使你确实有问题,当你的老板来询问时,你也可以把责任推到供应商身上。更不用说,一旦您第一次使用供应商的解决方案,其他部署将更快。这是正确的方法。

ASP.Net成员资格提供程序远非完美,但我向您保证,最好是从头开始构建它。

的优点 provider model are outlined here

1. 某些现成的webcontrol是为了使用成员资格提供者模型而构建的,例如 Login control/view 以及创建用户向导。因此,您错过了一个一步配置,即在没有编写任何代码的情况下为所有页面登录仪表板。

2. 只需在web.config文件中进行简单更改,就可以交换提供程序。并不是说你不能写你自己的登录资料来做同样的事,但你可以很容易地写一个自定义的提供者在某个点上的道路,并切换到你的应用程序,而不改变任何东西在应用程序中。

3. 提供了所有的基础知识。默认成员资格提供程序具有密码检索、帐户锁定、多种密码加密方法、有效的密码限制规则配置和用户管理,这些都是现成的。对于大多数从头开始使用ASP.Net应用程序的人来说,仅仅使用它就大大减少了安装时间。

4. 之前

我同意你的看法 Ayende's feelings about this :

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

这也是我的经历。每当我实现了自己的成员资格提供者(在本文撰写时两次)时,我都没有实现绝大多数被重写的方法,因为我从不调用它们,也没有使用任何使用它们的web表单控件。

如果Sql和activedirectory提供程序能够满足您的所有需求,那么它们就非常棒了。但是如果他们不这样做,而您正在考虑实现提供者,那么可能有一个更好的方法适合您。

FormsAuthentication ,我仍然经常依赖它来申请。这是一种机制,负责将用户的身份验证令牌包装在cookie中,并在客户端和服务器之间传递。就我所知,FormsAuthentication没有什么问题,我也不建议重新设计它。

如果你不想实现几十个 MembershipProvider methods , RoleProviderMethods ProfileProvider methods 那就实施吧 IPrincipal 和 IIdentity 做你该做的。 Here's an example 让这两个接口与FormsAuthentication一起工作,这是微不足道的。

另外,请注意,您需要聪明地存储用户的凭据。SqlMembershipProvider 做 Here's a nice piece of code 帮我解决这个问题。通知 the slow hashing algorithm used . 不要吸毒。

自从我写这篇文章以来,ASP.net中的情况发生了变化。 ASP.NET Identity 替换以前的成员资格功能。

我的建议是使用新材料,因为:

• 您可以完全更改存储标识数据的位置/方式,同时保留控制密码散列方式的默认实现。
• OAuth和OpenID特性。
• 您可以在任何基于OWIN构建的框架中使用相同的系统。

好 “坚持下去。”如果有什么东西能用,就别修了”等等。否则,考虑到成员API的程序员小时数、QA小时数和用户小时数是您自己能想到的任何东西的数千倍。

Which authentication and authorization schemes are you using - and why?

Microsoft Membership Provider Vs Custom Provider Vs Complete Custom Login System

Anyone uses ASP .NET Membership?

Alternatives to .Net Membership

会员资格不仅仅是会员资格(登录、电子邮件、密码和相关功能)。Aspnet将成员资格和概要文件分开,并且它们可以集成。个人资料就是你所谓的“额外领域”。

这就是你跳过它时基本上会错过的。

您可以实现一个提供者,而不是一次删除提供者模型。

在您的案例中,经过身份验证的用户是例外,而不是常规,因此您自己的用户可能不会受到影响。

net提供的一个功能是防止暴力攻击,如果有人试图暴力破解管理员密码,管理员帐户将被锁定。

FSCAuth 而且是BSD许可的。

我让它比ASP.Net的内置身份验证更难出错。所有的cookie处理和实际的散列都留给了FSCAuth的核心,而您所要担心的只是将用户存储在数据库中并控制哪些页面需要进行身份验证。

如果您面临的问题是ASP.Net的内置身份验证和您自己的身份验证,我建议您先看看我的身份验证库,如果不只是把它作为一个起点的话。