为什么应该使用 ASP.NET 成员身份安全模型？
我目前正在更新我的网站，并且认为如果我要更新我的登录/安全模式，现在是个好时机。
我已经浏览了 ASP.NET 中包含的成员资格模型，但我不相信它除了为其他 .NET 开发人员所熟悉之外还会提供任何好处。
似乎有很多关于它的文档，但很少讨论为什么它值得付出努力。
有人能解释一下吗？
I'm updating my website at the moment and figure that if I am to update my login/security mode, now is a good time.
I have looked through the Membership model which is included in ASP.NET but I'm not convinced that it will provide any benefit apart from being familiar to other .NET developers.
There seems to be quite a lot of documentation for it, but little discussion for why its worth the effort.
Can anybody shed some light upon this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我认为在大型网站上使用会员资格没有什么好处。 这已被宣传为 ASP.Net 身份验证的“最佳”解决方案。 然而，实际上，微软似乎只是试图将旧的会员服务器产品定位为每个人突然都需要的东西。
大约 10 年前，我在 MSFT 从事会员服务器工作。 也是 shop.microsoft.com 的首席开发人员，我可以告诉您，我们在该网站上没有使用任何内部服务器产品 - 不是商务服务器，不是会员服务器。 不知道他们现在是怎么做的——但我认为当时的普遍共识是，这些类型的软件包通常会妨碍我们想做的事情。
它对于较小的站点可能很有用，或者如果您的资源有限......即部门或小公司内部网的数百个用户，而您不想在其中投入太多时间或资源。 我越看越觉得它完全不适合大型定制网站。
我真正不明白的是，几乎每一本 ASP.Net 书籍似乎都将其视为唯一的方法，而不是一种方法。
I see little benefit to using membership for a large site. This has been marketed as 'the' solution for ASP.Net authentication. However, really it looks like Microsoft is just trying to position the old Membership Server product as soemthing that everyone all of a sudden needs.
I worked on Membership Server at Msft around 10 years ago. Was also a lead developer on shop.microsoft.com, and I can tell you we used no internal server products on that site--not commerce server, not membership server. Not sure how they are doing it now--but I think the general consensus at that point was that those type of packages generally got in the way of what we were trying to do.
It could be useful for a smaller site, or if you have limited resources... i.e. a few hundred users for a departmental or small company intranet, where you don't want to invest much time or resources. The more I look at it, the more it seems completely inappropriate for larger, custom web sites.
What I really don't understand is how almost every ASP.Net book seems to push this as the only way to do it, rather than one way to do it.
在阅读完 ASP.NET 会员资格提供程序中的所有存储过程后，我编写了自己的程序。 这并不难，而且最终您拥有更多的控制权。
如果您喜欢 XML 配置、角色的弱类型字符串、默认情况下不安全、目录中散落着随机的 web.config 文件，而不是页面类上干净的标记界面来表示“不需要帐户”、单个数据库的多个数据库命中登录、未从当前 ObjectContext/DataContext 加载的用户对象以及动态更改提供程序的能力（哇哦，谁使用它？！）选择内置的。
如果没有，请构建您自己的，但如果您这样做，请确保存储密码的加密/加盐哈希，并请执行适当的加密 cookie。
[已更新以反映评论中的反馈]
I wrote my own after reading through all the stored procedures in the ASP.NET Membership provider. It's not hard and you have much more control at the end of the day.
If you like XML configuration, weakly-typed strings for roles, insecure by default, random web.config files littered through your directories instead of a clean marker interface on your page classes to say 'no account required', multiple database hits for a single login, user objects that aren't loaded from your current ObjectContext/DataContext and the ability to change providers on the fly (woo hoo, who uses that?!) go for the built-in one.
If not, build your own, but if you do, make sure you store an encrypted/salted hash of your passwords, and do a proper encrypted cookie please.
[Updated to reflect feedback in comments]
除非您是唯一在该特定站点上工作的人，否则我认为 .NET 开发人员熟悉该站点这一事实是采用内置会员资格路线的一个很好的理由。 其他具有 ASP.NET 经验的开发人员可以跳入该项目并快速了解您网站的身份验证/授权模型。
我们在网站上使用内置的成员资格和角色提供程序模型，它运行得很好...我们必须编写自己的提供程序类，因为我们对数据使用不同的后备存储（我们使用 Microsoft Dynamics CRM），但是这些类非常简单并且有详细的文档。 通过预先完成这些工作，我们现在可以在代码中使用 Membership 和 Roles 类以及页面上的各种与登录相关的服务器控件。
您正在考虑其他选择吗？
Unless you are the only person who will ever work on this particular site, I think the fact that it is familiar to .NET developers is a good reason to go the built-in Membership route. Other developers with ASP.NET experience can jump into the project and get up to speed on your site's authentication/authorization model very quickly.
We use the built-in Membership and Role provider model on our site and it works very well...we had to write our own Provider classes, since we use a different backing store for the data (we use Microsoft Dynamics CRM), but these classes are pretty simple and well-documented. By doing this bit of work up front, we can now use the Membership and Roles classes in code as well as the various login-related server controls on our pages.
Is there another alternative that you are considering?
我真正讨厌 .Net 附带的 MembershipProvider 的唯一一点是 userid 是 GUID 而不是自动递增的身份。 我知道使用 GUID 有好处，但将其集成到预先存在的系统或模块中可能会很痛苦。
The only thing I really hate about the MembershipProvider that comes with .Net is the fact that the userid is a GUID instead of an auto incrementing identity. I know there are bonuses to using a GUID but integrating it into pre-existing systems or modules can be a pain.
它就在那里，这样您就不必自己动手。
It is there simply so that you do not have to roll your own.
它的价值在于它是一个易于使用的现成的基于角色的安全框架。 如果您已经构建了自己的框架并且迁移并不简单，那么它可能不值得。 但迁移的好处之一是您可以消除大量应用程序代码并用框架代码替换。
It's value is that it is an easy to use ready built role based security framework. If you have already built your own framework and migration is not trivial then it may not be worth it. But one benefit of migrating would be you could eliminate a lot of application code and replace with framework code.
如果您想将站点迁移到任何类型的已制作的门户软件 - 例如 Community Server 或 DotNetNuke，使用会员提供商可以轻松迁移。 您甚至可以使用现有数据库而不必实施新数据库。
If you ever want to migrate your site to any kind of already made portal software - like Community Server or DotNetNuke using the membership provider allows for easy migration. You can even use the existing database and not have to implement new ones.
我认为 ASP.NET 成员资格、角色和配置文件的一个引人注目的功能是它使用提供程序模型。 如果您对它的现状不满意，那么从基类中推出您自己的类并不困难。 如果您查看 codeplex.com，您可能会发现人们编写的十几个或更多自定义提供程序。 几年前我为 SQLite 数据库编写了一个。
I think a compelling feature of ASP.NET Membership, Role and Profile is that it uses the provider model. If you aren't happy with it the way it is, it is not difficult to roll your own from the base classes. If you look at codeplex.com you can find probably a dozen or more custom providers that people have written. I wrote one for the SQLite database a few years ago.
会员制路线运作良好，但有一个致命的缺陷，我不会为此责怪微软。
Internet Explorer 是唯一正确处理身份验证缓存的浏览器。
您可以关闭 Firefox 浏览器，打开它，然后恢复上次会话，然后直接返回“安全”网站，而无需登录。Chrome 也有类似的问题，Mac 也有同样的问题。
IE 有一个 javascript 调用可以正确处理此问题： document.execCommand("ClearAuthenticationCache", "false");
它不适用于任何其他浏览器。 如果您使用此功能，则需要强制用户使用 IE。
The Membership route works well BUT there is one fatal flaw and I do not blame Microsoft for it.
Internet Explorer is the only browser that properly disposes of the authentication cache.
You can close a Firefox browser, open it and then restore that last session and go right back into your "secure" website without logging in. Chrome has similar issues and anything Mac does the same.
IE has a javascript call that handles this correctly: document.execCommand("ClearAuthenticationCache", "false");
It does not work with any other browser. If you use this you need to force users to use IE.