ACL最佳实践,在用户对象中存储角色,还是单独的表/集合？

Question

我正在使用nodejs,并且过去一周一直在研究acl /授权.我发现只有一对,但似乎没有一个我需要的功能.最接近的是https://github.com/OptimalBits/node_acl,但我认为它不支持通过id保护资源(例如,如果我想允许用户12345并且只允许用户12345访问用户/ 12345/edit ).因此,我想我必须为自己制作一个自定义的acl解决方案.

我的问题是,在每个用户对象下存储角色(用户,管理员,管理员等)的优点和缺点是什么,而不是创建另一个用每个用户映射其授权规则的集合/表？node_acl使用单独的集合,而大多数其他集合依赖于用户对象中的roles数组.

顺便说一下,我现在正在使用Mongodb.但是我还没有研究使用关系数据库与非关系数据库进行身份验证的利弊,所以如果你的答案取决于那个,请告诉我.

当我打字时,我想到了一件事.如果我将角色存储在单独的集合中,则它更具可移植性.我可以更容易地换掉acl系统.(我认为？)

Answer 1

这里的问题似乎可以从"我应该在哪里存储我的角色"中抽象出"我应该如何在Mongo(或NoSQL中)存储相关信息".这是一个关系与非关系建模问题.

非关系

使用Node + Mongo,将角色存储在用户上将使得确定用户是否可以访问该功能非常容易,因为您可以查看"角色"属性.权衡是你有很多重复的信息('user_read'可能是每个用户帐户的角色),如果你最终改变了这个属性,你需要在每个用户对象内更新它.

您可以将角色存储在自己的集合中,然后将该条目的ID存储在User模型的Roles集合中,但是您仍然需要从集合中获取实际记录以显示其中的任何信息(尽管可以说是这可能是罕见的事情)

相关的

将这些存储在关系数据库中将是一种更"传统"的方法,因为您可以建立表之间的关系(通过FK /连接表或不存在).这可能是一个很好的解决方案,但是你不再拥有使用NoSQL数据库的好处.

摘要

如果您的应用程序的其余部分存储在Mongo中并且必须留在那里(为了性能或任何约束),那么您最好在Mongo中完成所有操作.我遇到的大多数建议都说不要混合和匹配数据存储,例如使用一个或另一个,但不能同时使用两者.话虽如此,我已经完成了两者的项目,它可能会变得混乱,但有时候专业人士会超过缺点.