我正在使用nodejs，并且在过去的一周一直在研究acl/授权。我只找到了两款，但似乎没有一款具备我所需要的全部功能。最接近的是https://github.com/OptimalBits/node_acl，但我认为它不支持通过id保护资源(例如，如果我想允许用户12345并且只有用户12345访问user/12345/edit)。因此，我认为我必须为自己制作一个自定义acl解决方案。
关于这一点，我的问题是，在每个用户对象下存储角色(user、admin、moderator等)，而不是创建另一个集合/表来映射每个用户及其授权规则，这有哪些优缺点? node_acl使用单独的集合，而大多数其他集合依赖于用户对象中的角色数组。
顺便说一下，我现在正在使用Mongodb。但是，我还没有研究使用关系数据库和非关系数据库进行身份验证的利弊，所以如果您的答案取决于此，请告诉我。
当我在打字的时候，我想到一件事。如果将角色存储在单独的集合中，则可移植性更强。我可以更容易地替换acl系统。(我认为)
这里的问题似乎可以从"我应该在哪里存储我的角色"抽象为"我应该如何在Mongo(或一般的NoSQL)中存储相关信息"。这是一个关系与非关系建模的问题。
非关系
使用Node + Mongo，将角色存储在用户身上，可以很容易地确定用户是否有访问该特性的权限，因为你可以查看'roles'属性。这样做的代价是你有很多重复的信息('user_read'可能是每个用户帐户上的一个角色)，如果你最终改变了这个属性，你需要在每个用户对象中更新它。
您可以将角色存储在它们自己的集合中，然后将该条目的id存储在用户模型的roles集合中，但是您仍然需要从集合中获取实际记录以显示其任何信息(尽管这可能很少发生)
关系
将这些存储在关系数据库中将是一种更"传统"的方法，因为您可以在表之间建立关系(通过fk/join表或其他方式)。这个可能是一个很好的解决方案，但是这样您就不再拥有使用NoSQL数据库的好处了。
如果你的应用程序的其余部分存储在Mongo和有留在那里(性能或任何约束)，那么你可能最好在Mongo做这一切。我遇到的大多数建议都是不要混在一起。匹配数据存储，例如，使用其中一个，但不要同时使用两个。话虽这么说，我用这两种方法都做过项目，可能会很混乱，但有时利大于弊。
我喜欢@DavidWelch的回答，但我想从另一个角度来解决这个问题，因为提到的库提供了完全使用不同数据存储的选项。
将角色存储在单独的数据存储中:
- (Pro)如果您使用更快的数据存储，可以使系统性能更高。(在分布式环境下更有利?)
- (Con)您必须确保两个数据存储之间的一致性。
将军指出:
- 您可以在acl中添加角色/权限，例如'blog123'。您还可以基于动词(例如put、delete、get等)授予用户权限。
- 我认为创建一个不依赖于存储实现的可插拔解决方案更容易。也许这就是为什么acl不将角色存储在与您相同的集合中。
- 如果您选择将角色保留在自己的集合中，请考虑将它们添加到令牌(JWT)中。这样，您就不必为每个需要授权的请求检查您的收集。
我希望这对你有帮助。