9

我正在使用nodejs，过去一周一直在研究acl/authorization。我只找到了几个，但似乎没有一个具有我需要的所有功能。最接近的是https://github.com/OptimalBits/node_acl，但我认为它不支持通过 id 保护资源（例如，如果我想允许用户 12345 并且只有用户 12345 访问 user/12345/edit ）。因此，我认为我将不得不为自己制作一个自定义的 acl 解决方案。

我的问题是，在每个用户对象下存储角色（用户、管理员、版主等），而不是创建另一个集合/表来映射每个用户及其授权规则，有哪些优点和缺点？node_acl 使用一个单独的集合，而其他大多数依赖于用户对象中的角色数组。

顺便说一句，我目前正在使用 Mongodb。但是，我尚未研究使用关系数据库与非关系数据库进行身份验证的优缺点，所以如果您的答案取决于此，请告诉我。

当我写这篇文章时，我想到了一件事。如果我将角色存储在单独的集合中，它会更便携。我将能够更轻松地更换 acl 系统。（我认为？）

4

2 回答 2

10

这里的问题似乎可以从“我应该在哪里存储我的角色”抽象为“我应该如何在 Mongo（或一般的 NoSQL）中存储相关信息”。这是一个关系与非关系建模问题。

非关系型

使用 Node + Mongo，将角色存储在用户上将非常容易确定用户是否有权访问该功能，因为您只需查看“角色”属性即可。权衡是你有很多重复的信息（'user_read' 可能是每个用户帐户上的一个角色），如果你最终更改了该属性，则需要在每个用户对象中更新它。

您可以将角色存储在他们自己的集合中，然后将该条目的 id 存储在 User 模型的 Roles 集合中，但是您仍然需要从集合中获取实际记录以显示它的任何信息（尽管可以说这可能是一种罕见的情况）

关系型

将这些存储在关系数据库中将是一种更“传统”的方法，因为您可以建立表之间的关系（通过 FK / 连接表或其他方式）。这可能是一个很好的解决方案，但是您将不再拥有使用 NoSQL 数据库的好处。

概括

如果您的应用程序的其余部分存储在 Mongo 中并且必须留在那里（出于性能或任何限制），那么您最好在 Mongo 中完成所有操作。我遇到的大多数建议都说不要混合和匹配数据存储，例如使用一个或另一个，但不能同时使用两者。话虽如此，我已经完成了两者的项目，它可能会变得一团糟，但有时利大于弊。

于 2013-01-12T18:03:16.583 回答
3

我喜欢@DavidWelch 的回答，但我想从另一个角度解决这个问题，因为提到的库提供了完全使用不同数据存储的选项。

将角色存储在单独的数据存储中：

  • (Pro) 如果您使用更快的数据存储，可以使系统性能更高。（在分布式环境中更有利？）
  • (Con) 您必须确保两个数据存储之间的一致性。

一般注意事项：

  • 您可以在acl中添加角色/权限，例如 'blog\123' 。您还可以根据动词（例如 put、delete、get 等）授予用户权限。
  • 我认为创建一个不依赖于您的存储实现的可插拔解决方案更容易。也许这就是 acl 不将角色存储在您拥有的相同集合中的原因。
  • 如果您选择将角色保留在自己的集合中，请考虑将它们添加到令牌 (JWT)。这样，您就不必为需要授权的每个请求检查您的集合。

我希望这有帮助。

于 2016-05-03T02:32:44.437 回答