如何避免使用会员提供商？

Question

我们目前正在为瘦客户端簿记应用程序构建架构。它应遵循两个主要要求：

1. 应用程序应具有模块设计。每个模块都可以拥有（并且实际上拥有）自己的角色系统。
2. 以后的应用程序应该适合在不同的机器上使用不同的数据库运行。

我们认为Asp.NET MVC 3是适合此任务的平台。为了管理应用程序数据，我们选择了最新版本的Entity Framework - 它的批量数据提供程序和Code First功能可以为我们节省很多时间。

我们纠结的部分是用户/角色管理系统。我们应该有一些全局管理部分用于添加用户并授予他们访问模块的权限（只有全局管理员可以将用户添加到系统，不支持“街头人”注册）并且每个模块都有自己的管理部分和自己的管理员和角色。我们已经有了数据模型来以适当的方式存储我们需要的所有内容，但不知道如何从应用程序中正确访问这些数据。

目前我们看到两种可能的方法来解决此问题：

1. 根据我们的DAL编写自定义成员资格和角色提供程序。我们团队中的任何人都没有这样做过，所以我们不确定这种方式是否值得。会员提供商不能提供与应用程序需求一样多的灵活性，因此需要一些紧急情况。
2. 深入挖掘一些过时的书籍，了解在成员资格提供者创建之前如何组织网站管理系统。

这两种方式都不优雅，对我们来说并不明显，并且选择哪种方式并不是一个简单的问题。我们也相信它可以是其他解决方案（原因可能会影响架构）。因此，我们很高兴看到任何与此问题相关的建议。

Answer 1

我个人建议首先使用标准会员资格提供程序来创建和验证用户，然后一旦确认用户不仅仅是某个“来自街头的人”，请使用您自己的自定义架构验证经过身份验证的用户是否可以访问他们尝试访问的控制器和操作。

内置成员资格提供程序负责处理用户身份验证，密码存储等方面的许多细微差别。它使用最佳实践来避免暴力攻击，彩虹表攻击等。这是经过验证的。

但听起来您的每个模块的权限结构可能适合或不适合ASP.NET角色提供程序的模式。如果他们这样做，这一切都很好，并且实现自定义角色提供程序是个好主意。但是，如果您的需求是“开箱即用”，那么您最好只需在最适合您的位置手动检查权限（控制器，操作，请求过滤器等）。

Answer 2

我建议您使用自定义会员提供商。为什么？导致它的标准方式，将为您节省大量的工作。它并不像我看到的那么难，而且有很多资源，如this one。

Answer 3

  

  
1. 根据我们的DAL编写自定义成员资格和角色提供程序。   我们团队中的任何人都没有这样做过，所以我们不确定是否这样   方式值得麻烦。会员提供商不能提供同样多的服务   应用程序需要灵活性，因此需要一些紧急情况。
  

如果默认设置不提供您需要的功能，那将非常值得。如果您的数据库中已有一个复杂的用户系统，那么自定义成员资格提供程序可能是个好主意。

它将为您的团队增添宝贵的经验，您应该能够在下一个项目中重用大部分代码。正如@Randolf所说，建立一个客户会员提供商有很多很好的资源，当我说它并不是那么困难时，我会从一些经验中说出来。一切都在那里，你只需要实现一些方法。

Answer 4

好吧，最后我们决定从头开始编写，它似乎更容易

• 添加自己的IPrincipal实现。 IsInRole（）方法的其他字段和完全不同的逻辑，以避免编写自己的属性。
• 将Global.ajax事件中的IPrincipal分配给用户。

一点都不难。现在我们拥有了我们想要的所有灵活性。没有提供者参与。