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

Question

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

我见过三种类型的解决方案：

• 使用内置的 ASP.NET 会员系统 (NerdDinner )
• 自己动手 (Shrinkr)
• 为 ASP.NET 成员资格创建一个抽象层 (Tekpub 的 mvcstarter 工具包）

我一直在阅读您的知情想法，许多人说尝试推出您自己的“用户系统”甚至可能是如果您不注意安全细节，则很危险。另一方面，解决方案要简单得多。所有内容可能都存储在一个数据库中，而用户特定的内容则存储在一个用户表中。该解决方案的开销似乎相当低。

使用 ASP.NET 成员资格解决方案允许使用许多开箱即用的功能，但恕我直言，这确实令人困惑。您可能需要将成员身份信息存储在其自己的数据库中，并以某种方式能够将用户实体从您的站点特定数据库链接到 ASP.NET 数据库。

如果您使用 ASP.NET 会员资格，

• 您的数据库架构是什么样的？如何创建与 ASP.NET 会员用户的外部关系（即歌曲<=>FavoriteSongs (<=>SiteUsers)<=>aspnet_Users）？
• 你为什么不自己滚？

如果您自己推出了

• 您使用了哪种用户系统抽象层（如果有）？
• 为什么不使用 ASP.NET 会员资格？

分析这些可能性我真的很不知所措。请把我从这个会员瘫痪的粘性网络中踢向正确的方向！谢谢。

Answer 1

内置的会员提供程序已经很安全并且非常易于使用。您可以在几个小时内启动并运行内置的会员资格。或者（取决于您正在构建的应用程序类型）您也可以使用 OpenID 进行检查，这就是StackOverflow 使用。

此外，通过内置的成员资格提供程序，创建关系就像使用“唯一标识符”将 aspnet_User 表（我记不起确切的名称）与相关表一样简单。

我将所有会员“内容”存储在与系统数据库相同的数据库中，并且它从未引导我出错。创建会员“东西”也很容易。只需运行 aspnet_regsql.exe 针对您想要拥有 asp.net 成员资格的数据库

这是另一个同样的问题。

Answer 2

许多人选择不推出自己的身份验证系统是有充分理由的！这是非常危险的，有很多小方法可能会导致您出错，从而使您的网站容易受到攻击。

然而，我是那些冒险家之一，并且确实自己做了。我仔细检查了每一行代码是否存在安全缺陷，自从发布了我的身份验证系统 1.0 以来，到目前为止我还没有修补过任何安全缺陷。无论如何，我的身份验证系统名为 FSCAuth 并获得 BSD 许可。

• 您使用了哪种用户系统抽象层（如果有）？

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

我的 UserData 类非常简单，只需要 4 个字段：Username、PasswordHash、UniqueID 和 Salt。这就是 FSCAuth 所依赖的。如果您需要更多字段，您可以继承 UserData 类，它的工作原理是一样的。

• 为什么不使用 ASP.NET 会员资格？

我发现内置 ASP.Net 身份验证有很多缺点

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

更困难。其中许多问题都是设计使然，我相信这是尝试制作一款让每个人都满意的软件的症状。

好吧，在 FSCAuth 中，我在设计上遗漏了很多东西，老实说，它不可能适合所有人。但在许多常见场景中，它比 ASP.Net 成员资格更容易使用。几乎可以使用世界上任何散列算法。用于身份验证的单个数据库命中。无状态登录。唯一 ID 可以是任何适合字符串的内容。等等。

因此，如果您在解决 ASP.Net 的内置身份验证和推出自己的身份验证之间犹豫不决，请先看看 FSCAuth。如果不出意外的话，它是您自己推出的一个很好的起点。