0

因为 RoleProvider 接口似乎将角色视为简单的字符串，所以我想知道是否有任何非 hacky 方法可以为每个用户应用角色的可选值。

我们当前的登录管理系统将角色实现为键值对，其中值部分是可选的，通常用于阐明或限制角色授予的权限。

例如，角色“editor”可能包含用户“barry”，但对于“barry”，它将具有可选值“raptors”，系统会将其解释为表示 Barry 只能编辑在“raptors”下提交的文章类别。

我在其他地方看到过一个建议，即简单地创建额外的分隔角色，例如“editor.raptors”或类似的角色。这并不理想，因为它会大大增加角色的数量，而且我可以说要替换我们当前的实现将是一个非常困难的销售（这也非常不理想，但具有定制的优势与我们的用户数据库一起工作）。

我已经可以看出，上面提到的连接方法将涉及大量繁琐的字符串拆分和部分匹配。

有没有更好的办法？

编辑：我最初的目标是使用更多内置的 ASP.NET 功能。例如，通过<authorization/>Web.config 中的元素控制访问。据我所知，这样做需要自己实现角色。除了这一限制之外，我们当前系统的身份验证概念似乎非常适合。

回答 mnemosyn 的问题

  1. 是的。我们有一个用于用户、应用程序及其授权的中央数据库。这是一个核心系统，无法绕过它。
  2. 目前我们的系统是没有层次的，实际上维护起来还是很费功夫的。创建应用程序时，会定义一组授权（例如，“admin”、“user”、“poweruser”、“gatekeeper”、“keymaster”等）。然后，用户将与那些具有可选值的授权相关联，以实现用户和（特定于应用程序的）授权的唯一组合。
  3. 您能否详细说明您所说的这些“类别”？
4

1 回答 1

1

对我来说，这听起来确实像是一个架构问题。

首先，您需要准确地确定您需要什么。在第二步中，将其映射到具体实现。跳过那个：除了最简单的情况外，我不会使用内置提供程序。此外，这个问题很快就会变得非常复杂，所以我会尽量保持简单。

要详细说明您的需求，请尝试确定：

  • 您真的需要像在 CMS 中那样将角色概念映射到数据库吗？或者对角色系统的更改是否意味着对系统的修改。在这种情况下，您可以采用更简单的解决方案并将枚举放入用户中。这将节省大量的数据库访问，使连接变得简单，等等。
  • 你试图通过你解释的多角色概念来实现什么？你真的需要角色吗？个人权限如何？例如，您是否有一个层次结构，以便每个节点都可以拥有与其关联的特定权限集，就像 Windows 的文件安全概念一样？
  • 如果只是类别，为什么不将类别映射到用户，即在每个类别中给每个用户一个特定的角色。这将需要对默认类别等进行一些调整。

那里有一些提示：不要使用白名单，始终使用黑名单。控制白名单是一件痛苦的事，尤其是。当很多规则聚集在一起时。例如，在 drupal 中，我认为这是主要缺陷之一（这就是为什么他们要重建它以在版本 7 中使用黑名单）。允许用户做他们不应该做的事情通常比相反的问题要大得多。

Windows 文件访问的概念非常复杂，因为它同时具有黑名单和白名单，而且还可以继承 - 所以尽量让您的解决方案比这更简单。

字符串连接对我来说听起来相当危险，无论如何我都会寻求更清洁的解决方案。这种类型的元逻辑让人头疼。

于 2010-03-28T23:45:38.150 回答