为RESTful设计资源权限优先级

Question

这不是有权在资源端点上发出GET / POST / PUT / DELETE请求。这是关于某些用户对某些资源具有GET / POST / PUT / DELETE请求权限。

在我们的应用程序中，我们将其称为访问控制列表（ACL），其中包含以下sqlalchemy架构

class ACL(db.Model):
    __tablename__ = 'acl'
    id = db.Column(db.Integer, primary_key=True)
    res_id = db.Column(db.Integer, nullable=True)
    res_type = db.Column(db.String(50), nullable=True)
    permission = db.Column(db.String(20), nullable=True)
    is_allowed = db.Column(db.Boolean, default=True)
    users = db.relationship("User", secondary=acl_users)
    created_at = db.Column(db.DateTime, default=datetime.datetime.utcnow)

此ACL与用户有多对多的关系，与每个资源有多对一的关系。这个ACL可以是四件事：

1. 如果res_id不为空并且用户不是空列表，则称为＆＃34;确切＆＃34; ，因为它指定特定用户对特定资源的权限
2. 如果res_id为空并且用户不是空列表，则称为＆＃34; Anything＆＃34; ，因为它指定了特定用户对任何资源的权限< / LI>
3. 如果res_id不为空且用户为空列表，则称为＆＃34;任何人＆＃34; ，因为它指定了特定资源的任何用户权限< / LI>
4. 如果res_id为空且用户为空列表，则称为＆＃34;任何＆＃34; ，因为它指定任何用户对任何资源的权限

我不确定这种设计是否常见，但它似乎拥有定义资源许可所需的一切。

问题如下：

如果资源有多个ACL，那么优先级应该是什么？

我们有三种选择：

1. 添加＆＃39;优先级＆＃39; ACL表上的列，让它确定优先级。这种方法很有意义，但是创建优先级考虑ACL的Fetch Collection查询会成为一场噩梦。
2. 错误＆gt;＆gt;真正。例如＆＃34;任何＆＃34;假王牌＆＃34;确切＆＃34;真正。如果＆＃34;任何人＆＃34;设置为False，没有用户拥有该资源的权限。这最容易进行Fetch Collection查询。
3. 确切＆gt;＆gt;任何人＆gt;＆gt;任何＆gt;＆gt;任何。即使＆＃34;任何人＆＃34;如果Exact用户设置为True，则为False，则除该用户之外的所有用户都有权限。制作Fetch Collection查询既不容易也不可能。

这三个选项中哪一个最能反映许可的常见做法？

Answer 1

我不知道其中任何一种都很常见，一般情况与我过去看过的权限有所不同。 （顺便说一下，我在查找其他人如何对我自己的问题做了权限的时候发现了这篇文章，所以感谢不同的观点！）

我之前的系统遵循非常标准的角色+权限+用户系统。 （很多）用户可以被分配到（多个）角色。 （很多）角色可以有（一个）父角色。 （很多）角色和（很多）用户可以被分配（很多）权限。权限是Allow或Deny以及正在控制的Operation或Resource。我们还有一个中立的＆＃34;许可，但它并非真正必要，并且往往会使已经很复杂的系统变得更糟。

我的结构方式是更具体的权限覆盖了不太具体的权限，因此用户胜过角色胜过ParentRole。在同一级别，Deny胜过允许。不相关的角色是＆＃34;相同的级别＆＃34;，以及任何一个对象的所有权限。没有单独的优先级控制来使事情复杂化，Roles的层次结构将其加入，并且用户的任何特定内容都是如此。

所以要回答你的问题，我认为你需要混合2和3，或者很可能只是3，因为你在一个级别上确实没有相互冲突的权限。确切的权限应该总是赢。我会说，任何东西都胜过任何人，因为＆＃34;一切＆＃34;仍然是特定于一个主题，而＆＃34;任何人＆＃34;特定于资源但不特定于任何特定用户。 Any显然是最不重要的，基本上是默认行为。