最近，一位同事建议使用内置的MS会员资格、角色和个人资料提供程序是一个坏主意。他并没有详细解释其中的原因，但是，他确实提到了，如果你在面向高容量站点工作，那么这种架构很糟糕。想知道社区对此有什么看法吗?想知道是使用自己的还是使用内置的MS提供程序更好吗?这个领域的最佳实践是什么?
这个问题可能会因为主观和争论而结束，但这里有一些比我聪明的人的好观点和意见的链接，供你考虑和决定:
- http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html
- 链接自上述文章，但值得自己的链接:http://www.codinghorror.com/blog/2008/05/openid-does-the-world-really-need-yet-another-username-and-password.html
- https://www.owasp.org/index.php/Guide_to_Authentication
我本人是互联网驾驶执照概念的坚定信徒。
滚动你自己的是一个坏主意，除非你真的没有强大的安全需求。一般来说，我们web开发人员不擅长安全。ASP。. NET会员工具是由擅长安全的人编写的——这些人在一家名声不佳的公司工作(在我看来)，他们需要通过把事情做好来证明一些东西。
但是，如果您必须在使用内置提供程序和使用自己的提供程序之间做出选择，我会反对您的同事所说的话。
尽管他们的名声不好，微软还是非常关心安全问题，这一点可以从免费提供给开发人员的大量安全信息中看出。我宁愿相信他们，也不愿相信自己有能力想出一个安全的系统。
至于性能，我对内置提供商没有任何负面体验，但我不认为我正在工作的网站是特别高的访问量(每天只有大约10,000次点击)。
最终编辑-
如果您使用内置提供程序，OWASP网站有关于推荐设置的信息:https://www.owasp.org/index.php/Reviewing_Code_for_Authentication
我使用内置提供商的经验是，它有时是有效的……我所做的一些项目所存在的问题是，它们并没有提供我们想要的那么多定制内容，或者它们所提供的定制内容太多了，所以我们不得不自己去做。当然，我在编程方面是一个菜鸟。
所以这真的取决于你想要什么。MS SQL提供程序将工作，并做你想要的开箱即用?太棒了!使用它。否则，我建议你自己做。
& lt;/opinion>
我已经使用Membership、Role和Profile模型来编写适合我需要的自定义提供程序，许多其他人也这样做了。您不会被锁定在Provider模型中。你需要做研究，确定它是否符合你的需求，并做出适当的决定。现在有了OpenId和更新的BrowserID等产品，它们可以很容易地与微软的提供商模型集成，从而实现您的目标。没人拿枪指着你的头。了解事实，做一些研究，然后决定什么是适合你的。如果你想看一些别人做过的好例子，在codeplex.com上搜索一下，那里有很多不同的产品。
Provider模型的主要问题是它来自ASP。在NET 2.0 web表单时代，可测试性的优先级远低于使组件易于使用。提供者模型鼓励使用静态类和静态方法来工作，这可能会使测试变得困难，并且这被嵌入到平台的身份验证和授权机制中，例如Membership.GetUser()及其对IIdentity.Name和RolePrincipal的使用以及Roles.IsUserInRole(string role)的使用是两个主要的例子。更重要的是，由于实例是如何被框架实例化和控制的，因此需要花一些时间强迫它们使用诸如控制反转和依赖注入之类的模式。这会导致人们提出自己的解决方案。
总之，提供者是ASP中可靠的身份验证和授权的可靠方法。网络应用程序。如果你知道你在做什么，你可以没有它们，但如果你不知道，要么花时间去理解它们是如何工作的，以及如何在你的系统中更灵活地提供类似的功能，或者只是使用它们，直到它们成为一个问题。