我正在使用 nodejs，过去一周一直在研究 acl/授权。我只找到了几个，但似乎没有一个具有我需要的所有功能。最接近的是https://github.com/OptimalBits/node_acl，但我认为它不支持通过 id 保护资源（例如，如果我想允许用户 12345 并且只有用户 12345 访问 user/12345/edit）。因此，我认为我必须为自己制作一个自定义的 acl 解决方案。
我的问题是，在每个用户对象下存储角色（用户、管理员、版主等）有什么优点和缺点，而不是创建另一个集合/表来映射每个用户及其授权规则？ node_acl 使用单独的集合，而其他大部分依赖于用户对象中的角色数组。
顺便说一句，我目前正在使用 Mongodb。但是，我尚未研究使用关系数据库与非关系数据库进行身份验证的优缺点，所以如果您的答案取决于此，请告诉我。
在我打字的时候，我想到了一件事。如果我将角色存储在单独的集合中，它会更便携。我将能够更轻松地更换 acl 系统。 （我想？）
【问题讨论】：
这里的问题似乎可以从“我应该在哪里存储我的角色”抽象为“我应该如何在 Mongo（或一般的 NoSQL）中存储相关信息”。这是一个关系与非关系建模问题。
非关系
使用 Node + Mongo，将角色存储在用户上将非常容易确定用户是否有权访问该功能，因为您只需查看“角色”属性即可。权衡是你有很多重复的信息（'user_read' 可能是 每个 用户帐户上的一个角色），如果你最终更改了该属性，你需要在 中更新它>每个用户对象。
您可以将角色存储在他们自己的集合中，然后将该条目的 ID 存储在 User 模型的 Roles 集合中，但是您仍然需要从集合中获取实际记录以显示其中的任何信息（虽然可以说这可能是一种罕见的情况）
关系
将这些存储在关系数据库中将是一种更“传统”的方法，因为您可以建立表之间的关系（通过 FK/连接表或其他方式）。这个可以是一个很好的解决方案，但是你不再有使用 NoSQL 数据库的好处。
总结
如果您的应用程序的其余部分存储在 Mongo 中并且 必须 保留在那里（出于性能或任何限制），那么您最好在 Mongo 中完成所有这些。我遇到的大多数建议都说不要混合和匹配数据存储，例如使用其中一种，但不能同时使用。话虽这么说，我已经完成了两者的项目，它可能会变得混乱，但有时利大于弊。
【讨论】：
我喜欢 @DavidWelch 的回答，但我想从另一个角度解决这个问题，因为提到的库提供了完全使用不同数据存储的选项。
将角色存储在单独的数据存储中：
一般说明：
希望对你有所帮助。
【讨论】：