不使用MembershipProvider构建Asp.net mvc 3的缺点

除了必须自己编写所有内容之外，不使用MembershipProvider作为asp.net mvc 3应用程序有任何根本的缺点吗？ 我想知道是否有更大的东西我错过了它更容易。

授权属性是否适用于控制器？

谢谢。

Answer 1

AuthorizeAttribute绝不依赖于ASP.NET成员资格。 它只是查看HttpContext.User 。 什么设置将起作用。

“自己动手”的最大缺点是，大多数人，甚至是专家，都会犯这样的错误。 授权很难 ，最终，远远少于搜索现成解决方案的工作要少得多，而不是通过尝试自己制作国家新闻来恢复。

如果你认为自己这样做会让事情变得“容易得多”，那么你几乎肯定低估了问题的范围。

Answer 2

自己实现成员资格非常棘手。 您可以构建和调试它，它似乎可以工作，但您[可能]没有意识到您的架构是可以破解的。 在大多数情况下，它发现时已为时已晚。

例如：用于保存登录用户的加密cookie的算法。 如果可以预测或计算，黑客将很容易代表其他用户输入您的应用程序。 另一个潜在的安全问题可能是如果您使用错误的算法来加密/加密用户在数据库中的密码（据我所知，索尼有明文密码，一旦黑客攻击内部就会泄露。但我不确定那。）

除了严重的安全问题之外，实施MembershipProvider还为您提供了一系列function，如帐户锁定，密码强度实施，密码到期实施，可选角色方案等。

Answer 3

你失去了速度和安全性（就像你提到的那样），虽然你获得了灵活性/定制化，可能是一个很好但很难学习的经验