过去几天我一直在研究这个问题。
我们正在开发一个需要支持100,000多名用户的ASP.Net MVC网站。我们希望保持快速,可扩展和简单。我们有自己的用户和user_role等SQL数据库表。我们没有使用服务器控件。
鉴于没有服务器控件,并且需要创建自定义membershipProvider,使用ASP.Net Auth / Membership还有什么好处?
另一种选择似乎是创建自定义代码以在Cookie中删除UniqueID CustomerID并对其进行身份验证。或者,如果我们对嗅探器产生偏执,我们也可以加密cookie。
在这种情况下(MVC和客户数据在我们自己的表中)是否有任何真正的好处,使用ASP.Net auth / membership框架,或者完全自定义解决方案是否可行?
更新:我发现一个人(马特布里格斯)似乎得出了我的一些相同的结论:这来自这个链接: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会员资格很差 工程API不安全 盒子,维护得不好,而且 给开发人员一种虚假的感觉 安全。身份验证是一个周末 如果你没有建造一个项目 框架,但仍然是,大多数.net 开发商盲目跟随官方 API,假设一个主要的 像MS这样的公司可以推出 不错的东西。
答案 0 :(得分:6)
创建安全身份验证系统的首要规则之一是您不应该尝试自己构建框架。有许多陷阱很容易被忽视。所以,我想说除非有其他压倒性的理由,否则你应该使用像MembershipProvider这样的现有框架。
列出“好处”需要列出FormsAuthentication类所采取的所有安全措施,这是一个很长的列表。在我的头脑中,我可以想一些:
答案 1 :(得分:4)
在阅读了ASP.NET成员资格提供程序中的所有存储过程之后,我编写了自己的文档。这并不难,你在一天结束时有更多的控制权。
如果您喜欢XML配置,角色的弱类型字符串,默认情况下不安全,随机的web.config文件遍布您的目录,而不是页面类上的干净标记接口,表示“无需帐户”,多个数据库命中对于单个登录,未从当前ObjectContext / DataContext加载的用户对象以及动态更改提供程序的能力(woo hoo,谁使用它?!)用于内置的。
如果没有,请构建您自己的,但如果您这样做,请确保添加盐并加密您的密码,并请做一个正确的加密cookie。
答案 2 :(得分:2)
为了澄清潜在的误解,使用加密与否的客户ID非常容易受到嗅探器的攻击。您要做的是在成功验证时创建登录票证并将该ID存储在cookie中。这不会保护嗅探器免于窃取会话,但至少会话(最终)到期而客户ID不会。
答案 3 :(得分:0)
如果您希望拥有自己的存储空间,可以实施自己的会员提供商(如您所述)。一个优点是您可以通过IIS的.NET用户配置工具管理成员资格。
最大的优势是其他人已经说过的;为什么重新发明轮子?
如果您使用MVC实现自己的自定义登录UI,则在切换到其他成员资格提供程序时也可以重复使用。
答案 4 :(得分:0)
您可以自定义以构建自己的提供程序。在幕后,成员资格提供程序使用与您编写的相同的FormsAuthentication实现。无论如何,我已经读过,您将面临的性能的主要问题将与检索数据的SQL SERVER存储过程有关。在其中一本关于通过Omar Al Zabir构建门户系统的书中,他提到了对存储过程的一些改进,这可以提高性能。