将 ASP.Net 身份验证与 ASP.Net MVC 结合使用有什么真正的好处吗？
这几天我一直在认真研究这个问题。
我们正在开发一个 ASP.Net MVC 站点，需要支持 100,000 多个用户。我们希望保持它快速、可扩展且简单。我们有自己的 user 和 user_role 等 SQL 数据库表。我们没有使用服务器控件。
鉴于没有服务器控件，并且需要创建自定义membershipProvider，那么使用 ASP.Net Auth/Membership 还有什么好处吗？
另一种选择似乎是创建自定义代码以将 UniqueID CustomerID 放入 cookie 中并使用该代码进行身份验证。或者，如果我们对嗅探器很偏执，我们也可以对 cookie 进行加密。
在这种情况下（MVC 和客户数据位于我们自己的表中）使用 ASP.Net 身份验证/成员资格框架是否有任何真正的好处，或者完全自定义的解决方案是可行的途径吗？
更新：我发现一个人（马特·布里格斯）似乎得出了与我相同的结论：这来自此链接：http:// webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1< /a>
ASP.net 会员资格很差 设计的 API 不安全 盒子维护得不好，并且 给开发者一种错误的感觉 安全。认证是周末 如果您不构建项目 框架，但仍然是大多数 .net 开发商盲目跟风 API，假设主要 像MS这样的公司可以推出 一些不错的东西。
I've been researching this intensely for the past few days.
We're developing an ASP.Net MVC site that needs to support 100,000+ users. We'd like to keep it fast, scalable, and simple. We have our own SQL database tables for user and user_role, etc. We are not using server controls.
Given that there are no server controls, and a custom membershipProvider would need to be created, where is there any benefit left to use ASP.Net Auth/Membership?
The other alternative would seem to be to create custom code to drop a UniqueID CustomerID in a cookie and authenticate with that. Or, if we're paranoid about sniffers, we could encrypt the cookie as well.
Is there any real benefit in this scenario (MVC and customer data is in our own tables) to using the ASP.Net auth/membership framework, or is the fully custom solution a viable route?
Update: I found one person (Matt Briggs) who seems to have come to some of the same conclusions I have: This comes from this link: http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1
ASP.net membership is a poorly
engineered API that is insecure out of
the box, is not well maintained, and
gives developers a false sense of
security. Authentication is a weekend
project if you aren't building a
framework, but still, most .net
developers blindly follow the official
APIs, assuming that a major
corporation like MS can put out
something decent.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
创建安全身份验证系统的首要规则之一是您不应该尝试自己构建框架。有很多容易被忽视的陷阱。因此，我想说，除非有压倒性的理由不这样做，否则您应该使用现有的框架，例如 MembershipProvider。
要列出“好处”，需要列出 FormsAuthentication 类所采取的所有安全措施，这是一个很长的列表。我突然想到一些：
....
One of the first rules of creating a secure authentication system is that you shouldn't try to build the framework yourself. There are many pitfalls that can be easily overlooked. So, I would say unless there is an overwhelming reason to do otherwise, you should use an existing framework like the MembershipProvider.
To list "the benefits" requires listing all security measures that were taken by the FormsAuthentication classes which is a long list. Off the top of my head, I can think a few:
....
在阅读完 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 add salt and encrypt your passwords, and do a proper encrypted cookie please.
只是澄清一个潜在的误解，使用客户 ID（无论是否加密）都极易受到嗅探者的攻击。您想要做的是在成功验证时创建一个登录票证并将该 ID 存储在 cookie 中。这不会保护嗅探器窃取会话，但至少会话（最终）会过期，而客户 ID 不会。
Just to clear up a potential misconception, using the customer ID, encrypted or not is extremely vulnerable to sniffers. What you want to do instead is create a log in ticket at the time of successful authentication and store that ID in the cookie. This won't protect sniffers from stealing sessions, but at least the session (eventually) expires whereas the customer ID does not.
如果您希望拥有自己的存储空间，您可以实现自己的会员提供商（如您所提到的）。优点之一是您可以通过 IIS 的 .NET 用户配置工具来管理成员身份。
最大的优点是其他人已经说过的；为什么要重新发明轮子？
如果您使用 MVC 实现自己的自定义登录 UI，则在切换到不同的会员提供商时也可以重复使用。
You can implement your own membership provider (as you mentioned) if you wish to have your own storage. One advantage is that you can administer memberships through IIS' .NET users configuration tool.
The biggest advantage is what the others stated already; why reinvent the wheel?
If you implement your own custom login UI using MVC you could reuse also when switching for a different membership provider.
您可以自定义构建您自己的提供程序。在幕后，会员资格提供程序使用与您将编写的相同的 FormsAuthentication 实现。不管怎样，我已经了解到您将面临的性能主要问题与检索数据的 SQL SERVER 存储过程有关。在 Omar Al Zabir 撰写的一本关于构建门户系统的书中，他提到了对存储过程的一些改进，这些改进可以提高性能。
You can customize to build your own provider. Behind the scenes the Membership provider uses the same FormsAuthentication implementation as you will write. Anyway, I have read that the main issues about the performance you will face will be related to the SQL SERVER stored procedures that retrieve the data. In one of the books about building a portal system by Omar Al Zabir he mentions some improvements to the stored procedure which can result in faster performance.