如何避免使用会员资格提供程序

本文关键字：程序 何避免 | 更新日期: 2023-09-27 18:04:05

我们目前正在构建瘦客户机簿记应用程序的体系结构。它应该遵循两个主要要求:

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

我们认为Asp。NET MVC 3是适合此任务的平台。为了管理应用程序数据，我们选择了最新版本的实体框架-它的批量数据提供程序和代码优先特性可以节省我们很多时间。

我们纠结的部分是用户/角色管理系统。我们应该有某种类型的全局管理部分添加用户，并给予他们访问模块(只有全局管理员可以添加用户到系统，没有"家伙从街"注册支持)，每个模块都有自己的管理部分与自己的管理员和角色。我们已经有了数据模型来以适当的方式存储我们需要的一切，但是不知道如何从应用程序中正确地访问这些数据。

目前我们看到两种可能的方法来解决这个问题:

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

这两种方式对我们来说都不优雅，也不明显，选择哪一种方式不是一个容易的问题。我们也相信这可能是其他解决方案(因为架构可能会受到影响)。因此，我们很高兴看到任何与这个问题有关的建议。

如何避免使用会员资格提供程序

我个人建议首先使用标准成员资格提供程序来创建和验证用户，然后在验证了用户不是某个"路人甲"之后，使用您自己的自定义体系结构来验证经过身份验证的用户是否有权访问他们试图访问的控制器和操作。

内置会员资格提供程序处理了许多关于用户身份验证、密码存储等方面的细微差别。它使用最佳实践来避免暴力攻击、彩虹表攻击等。这是久经考验的真理。

但是听起来你的每个模块权限结构可能适合也可能不适合ASP的模式。NET角色提供者。如果他们这样做了，那就太好了，实现自定义角色提供者将是一个好主意。但是如果你的需求是"跳出框框"，你最好在最适合你的地方手动检查权限(控制器、动作、请求过滤器等)。

我建议您使用自定义成员资格提供程序。为什么?因为这是标准的方式，将节省你大量的工作。这并不像我想象的那么难，而且有很多类似的资源

  1. 根据我们的DAL编写自定义成员和角色提供者。我们团队之前没有人这样做过，所以我们不确定这是否值得这么麻烦。会员提供商不能提供这么多
    2. 应用程序需要的灵活性，因此需要一些碾压。

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

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

最后，我们决定从头开始编写，这看起来更容易。

    添加自己的IPrincipal实现。额外的字段和IsInRole()方法完全不同的逻辑，以避免编写自己的属性。
  • 在Global中分配IPrincipal。

一点也不难。现在我们有了我们想要的所有灵活性。

相关文章：