API 和数据库访问控制架构
API and Database Access Control Architecture
我正在尝试为 Survey 应用程序实施基于访问的控制，但在设计功能架构时遇到了问题。 DAC 似乎很适合我正在尝试做的事情，但我不确定。
层次结构
调查系列 -> 多个 Collection 的调查（1 个调查需要多人完成）-> 调查。
例子
我有调查经理需要分配 collection 个创建者。 Collection 创建者将用户分配给属于 collection 的调查。每个用户可以根据每个系列、Collection 或调查进行不同的访问控制。
用户 1 只能查看分配给他的调查，但也可以将属于特定 collection 的调查分配给其他用户，因为他被另一个 Collection 创建者授予访问权限.
用户 2 只能查看他创建的 collections，并有权访问和查看每个 collection.
中分配的调查
用户 3 可以创建系列，但不能查看他未指定为 collection 创作者的任何 collection 用户。
总结
访问权限应该是hieracle。每条记录（系列、Collection、调查）都有自己的一组访问控制 [创建、读取、查看、更新]，用户委托这些控制。我可以在设计模型方面得到一些帮助吗？
不幸的是，在数据库中实现这样一个复杂的分层授权模型……并不简单。鉴于提出的要求（跨多种资源类型的相似角色）以及对这些角色“继承”的需要，我概述了一个可能的模型来存储角色：
Name
Kind
Description
user_id
Foreign Key
The user that has this role
role
Enum
The role
survey_id
FK or NULL
The survey to which the role applies
collection_id
FK or NULL
The collection to which the role applies
series_id
FK or NULL
The series to which the role applies
table 中的每一行将包含一个用户、他们的角色，以及该角色适用的{survey, collection, series} 之一。这将允许您的应用程序轻松查找您正在检查的给定资源的角色（标准化的）。这是一个类似于 Django 中的 的模式。但是，它仍然存在一个关键问题：层次结构。
一个选项是在您的代码中定义一个函数，该函数知道要为您的层次结构的每个级别查找哪些角色，因此如果给它一个 survey，它会查找所有用户的角色级别 (survey、collection、series) 和 returns 具有最大访问权限的角色进行检查。否则，您可能需要使用一系列联接来 select 用户和传入资源的所有角色，随着 table 变大，这可能会变得非常慢。这也仅在您的角色在每个级别保持不变时才有效；否则，你很快就会发现自己
比较不同的角色枚举。
这类分层问题经常出现在权限检查中，您的不安是因为您认识到很难将它们映射到传统关系数据库中：权限关系的核心是 图，而关系数据库并不是为图的轻松遍历而设计的。
由于这种复杂性，有 services (this one is mine) that abstract away this complexity for you, so you can define your roles and relationships and not have to worry about the traversals. As a demonstration, I took the requirements you listed above and wrote an example in our playground，这可能有助于您可视化和测试这些关系。
我正在尝试为 Survey 应用程序实施基于访问的控制，但在设计功能架构时遇到了问题。 DAC 似乎很适合我正在尝试做的事情，但我不确定。
层次结构
调查系列 -> 多个 Collection 的调查（1 个调查需要多人完成）-> 调查。
例子
我有调查经理需要分配 collection 个创建者。 Collection 创建者将用户分配给属于 collection 的调查。每个用户可以根据每个系列、Collection 或调查进行不同的访问控制。
用户 1 只能查看分配给他的调查，但也可以将属于特定 collection 的调查分配给其他用户，因为他被另一个 Collection 创建者授予访问权限.
用户 2 只能查看他创建的 collections，并有权访问和查看每个 collection.
中分配的调查用户 3 可以创建系列，但不能查看他未指定为 collection 创作者的任何 collection 用户。
总结 访问权限应该是hieracle。每条记录（系列、Collection、调查）都有自己的一组访问控制 [创建、读取、查看、更新]，用户委托这些控制。我可以在设计模型方面得到一些帮助吗？
不幸的是，在数据库中实现这样一个复杂的分层授权模型……并不简单。鉴于提出的要求（跨多种资源类型的相似角色）以及对这些角色“继承”的需要，我概述了一个可能的模型来存储角色：
| Name | Kind | Description |
|---|---|---|
| user_id | Foreign Key | The user that has this role |
| role | Enum | The role |
| survey_id | FK or NULL | The survey to which the role applies |
| collection_id | FK or NULL | The collection to which the role applies |
| series_id | FK or NULL | The series to which the role applies |
table 中的每一行将包含一个用户、他们的角色，以及该角色适用的{survey, collection, series} 之一。这将允许您的应用程序轻松查找您正在检查的给定资源的角色（标准化的）。这是一个类似于 Django 中的
一个选项是在您的代码中定义一个函数，该函数知道要为您的层次结构的每个级别查找哪些角色，因此如果给它一个 survey，它会查找所有用户的角色级别 (survey、collection、series) 和 returns 具有最大访问权限的角色进行检查。否则，您可能需要使用一系列联接来 select 用户和传入资源的所有角色，随着 table 变大，这可能会变得非常慢。这也仅在您的角色在每个级别保持不变时才有效；否则，你很快就会发现自己
比较不同的角色枚举。
这类分层问题经常出现在权限检查中，您的不安是因为您认识到很难将它们映射到传统关系数据库中：权限关系的核心是 图，而关系数据库并不是为图的轻松遍历而设计的。
由于这种复杂性，有 services (this one is mine) that abstract away this complexity for you, so you can define your roles and relationships and not have to worry about the traversals. As a demonstration, I took the requirements you listed above and wrote an example in our playground，这可能有助于您可视化和测试这些关系。