使用/编写.Net自定义成员资格提供程序有哪些缺点？

最近，我在SO上发布了以下问题：https : //stackoverflow.com/questions/7197337/using-asp-net-membership-provider-with-an-existing-user-database

您可能会注意到，我最后回答了我自己的问题，指出编写/实现“自定义成员资格提供程序”看起来是一种方法。

从字面上看，几分钟后，我偶然发现了这个问题：https : //stackoverflow.com/questions/7222306/simple-login-attempt-counter-using-mvc-3-and-ajax/7222407#7222407

我尝试回答并获得评论，.Net成员资格提供程序“在许多级别上都很糟糕”。我承认，这是我第一次使用会员资格提供程序，但对我来说确实如此。

我没有看到任何支持“可怕”主张的东西，因此在实施“可怕”之前，我希望能从社区中得到一些反馈。

因此，我不确定“糟糕”是否是最好的词。但是，它有局限性，一旦您的需求不符合成员资格提供者的设计方式，您就会得到很多胶合代码。如果您可以直接使用会员资格提供者，那就说吧。无论如何，一旦您开始编写自定义内容，我都会使用会员资格问题。

以我的经验，会员提供者会购买您...

• 已为MVC应用内置的注册
• 帐号编辑
• 忘记密码很容易挂钩
• 验证用户方法

我敢肯定我还缺少其他东西，但我认为这些都是大问题。现在，当您需要自定义密码管理，两因素身份验证以使用现有数据模型或其他所有功能时，您就开始迷失了方向。如果您知道自己在做什么，那么为成员资格提供的已经为您编写的代码将需要几天的时间才能重复。

它无法满足您的需求。乍一看，您可能会发现它可以满足您的所有需求和某些需求，但是提出了新的要求。现在，您“真的”必须学习这东西是如何工作的。由于您处于这种错误的安全意识之下，因此拥有所有这些预构建的好处将减少。

@Travis提到使用现有数据模型，但是数据库的选择也可能会受到限制：Oracle？

我不知道它是否可与Facebook或Google等第三方验证系统一起使用。

它们不像许多人在快速阅读文档时所认为的那样灵活，但是它们有自己的位置。

如果您不需要控制用户令牌，而只需要构建自定义/扩展的用户数据或成员资格集，或者需要从现有/不同来源中提取数据，则可以使用它们。

如果您想进行更多更改，通常最好替换运行身份验证提供程序之一的httpmodule，那么您将获得所有控制权。在此级别，我遇到的大多数人都与提供程序有关的问题而做出了错误的选择。

无论哪种方式，您都会获得一个适当填充的context.user，它使您可以继续使用大多数基于asp.net的用户功能。

这个问题很旧，但是由于它的受欢迎程度我得到了徽章，所以我认为提供一个更新的答案是值得的。

在我的拙见中，微软的“简单”会员资格提供商终于做到了。如果您要编写新的东西，甚至使用新的应用程序将其附加到旧数据库。使用简单的成员资格提供程序。实施方式更简单，更清洁。安装几个表，然后将提供程序指向您的用户列表，您基本上已经完成。

该链接可以帮助您入门或只是谷歌搜索它：http : //www.mattjcowan.com/funcoding/2012/11/10/simplemembershipprovider-in-mvc4-for-mysql-oracle-and-more-with-llblgen/