ASP.NET会员资格：要还是不要？

Question

我正在考虑如何使用ASP.NET和MVC2实现授权和身份验证。我们可以将其称为用户系统。

在实践中，我看到了三种解决方案：

- 使用内置的ASP.NET Membership系统（NerdDinner） - 自己编写（Shrinkr） - 为ASP.NET Membership创建抽象层（Tekpub's mvcstarter kit）

我已经阅读了许多人的想法，并且很多人认为自己编写“用户系统”可能会更加危险，如果您没有注意安全细节。另一方面，该解决方案要简单得多。所有内容都可能存储在一个数据库中，并且用户特定的信息存储在一个用户表中。这种解决方案的开销似乎相当低。

使用ASP.NET成员资格解决方案可以使用许多开箱即用的功能，但在我看来，它真的很令人困惑。您可能需要将成员资格内容存储在自己的数据库中，并以某种方式能够将用户实体从您网站特定的数据库链接到ASP.NET上。

如果您正在使用ASP.NET成员资格：

- 您的数据库模式是什么样子的？如何创建与ASP.NET成员资格用户的外键关系（例如 Songs <=> FavoriteSongs (<=> SiteUsers) <=> aspnet_Users）？ - 为什么不自己开发？

如果您已经自己开发了：

- 您使用了什么类型的用户系统抽象层（如果有的话）？ - 为什么没有使用ASP.NET成员资格？

我真的被分析这些可能性所麻痹了。请从成员资格麻烦的粘性网络中给我指点方向！谢谢。

- nextgen

Answer 1

内置的成员资格提供程序已经很安全，而且非常容易使用。您可以在几个小时内使用内置的成员身份验证功能。或者（取决于您正在构建的应用程序类型），您还可以查看使用OpenID，这是StackOverflow使用的内容。

此外，使用内置的成员身份验证提供程序，创建关系就像使用“uniqueidentifier”将aspnet_User表（我无法记住顶部的确切名称）与相关表关联一样容易。

我将所有成员身份验证“东西”存储在与系统数据库相同的数据库中，它从未让我失望。创建成员身份验证“东西”也很容易。只需针对要拥有asp.net成员身份验证的数据库运行aspnet_regsql.exe即可。

这里有另一个SO问题与此类似。

- Chase Florell

Answer 2

许多人选择不自己编写身份验证系统，有很好的理由！这是相当危险的，有许多小细节你可能会做错，从而使你的网站容易受到攻击。

然而，我是那些冒险家之一，确实自己编写了身份验证系统。我反复检查了每一行代码是否存在安全漏洞，到目前为止，自从我发布1.0版身份验证系统以来，我还没有修补任何安全漏洞。无论如何，我的身份验证系统名为FSCAuth，并且采用BSD许可证。

• 如果有的话，您使用了什么样的用户系统抽象层？

我不太确定您的意思。我基本上只有一个层次，其中用户数据从数据库中检索和写入。一个层次，FSCAuth实际上处理cookie和HTTP身份验证。还有一个层次，您告诉FSCAuth“嘿，只有当前用户在管理员组中才能看到此页面”。

我的UserData类非常简单，只需要4个字段：用户名、密码哈希、唯一ID和盐。这就是FSCAuth所依赖的。如果您需要更多字段，可以从UserData类继承，它将完全相同。

• 为什么你没有使用ASP.NET成员资格？

我发现内置的ASP.Net身份验证存在许多缺点：

1. 如果您想使用内置成员资格提供程序以外的任何内容，则必须编写大量代码。
2. 有时您必须自己处理cookie，这是危险的。
3. 几乎不可能使用Blowfish哈希算法。
4. 每个页面加载需要多次往返数据库。
5. 有状态会话（用户登录时，记录会放入数据库），这使得扩展到多个服务器更加困难，并且通常会给数据库服务器带来更多不必要的压力。
6. 细粒度的身份验证（可以查看A人的电子邮件，但不能查看B人的）比我想象的更加困难。
7. 全局唯一标识符（GUIDs）。

其中许多问题是设计上的，我认为这是试图制作一个能够满足所有人需求的软件的症状。

嗯，在 FSCAuth 中，我故意留下很多东西，老实说它并不适合所有人.. 但在许多常见情况下，它比 ASP.Net 成员身份更容易使用。可以使用任何哈希算法。身份验证只需一个数据库查询。无状态登录。唯一的 ID 可以是任何符合字符串长度的东西。等等。

所以，如果你在决定是否绕过 ASP.Net 的内置身份验证和自己开发之间犹豫不决，请先看看 FSCAuth。即使什么都不行，它也是开发自己身份验证的很好起点。

- Earlz