我有一个“关系”模型,具有以下类型:
用户可以属于多个组,组可以有多个用户。
项目具有允许对其进行读取或执行操作的用户和组。
最常见的查询是,用户通过其 id 查询项目。为此,必须检查用户是否具有查询项目所需的权限。换句话说,它或其组之一必须对该项目具有权限。
到目前为止我想出了什么
一个解决方案是,这些项目具有以下属性:
用户
项目:
'data'
: 这个项目的数据<user/group-id>
: 此用户或组的权限因此,要检查权限,必须
问题
我觉得这可能会导致大量查询,尤其是当组数很高时。
有没有办法在没有如此昂贵的权限检查的情况下实现这个权限模型(或类似的权限模型)?
简短回答 -将您的权限与数据分开。
答案很长——你应该使用一个轻量级的权限表来存储组、用户和项目之间的关系。您不应在您的项目上使用任何与权限相关的排序键,除非您有特定原因允许具有相同 Id 的项目(例如存储项目的版本历史),否则您可能根本不应该使用任何排序键为您的项目。
权限表有两个属性,我称之为entity
(散列键)和relationship
(排序键)。(不过,您可以使用任何您想要的名称。)该表还有一个 GSI,其中relationship
是散列键和entity
排序键。由于该表的行很小,因此查询成本非常低。您可能会读取超过 100 行并仅消耗 1 个 RCU。
该entity
属性只是一个 userId 或 groupId。该relationship
属性是关系类型和另一个 ID 的组合。(您可以使用任何您想要的 ID,但我将在所有示例中使用数字。)
以下是一些示例数据:
entity | relationship
===========================================
user-0001 | member-of:group-1000
user-0001 | member-of:group-3000
user-0002 | can-access:item-1111
user-0002 | member-of:group-2000
group-1000 | can-access:item-1111
group-2000 | can-access:item-2222
Run Code Online (Sandbox Code Playgroud)
要确定用户是否有权访问给定项目,您需要进行两次查询。查询userId 的权限表,查询GSI 中的“can-access”itemId 关系。然后,比较两个查询结果,看看是否有共同的组(或者用户是否有权限直接访问该项目)。
例如,如果您想查看是否user-0001
可以访问item-1111
,您可以查询user-0001
并返回[member-of:group-1000, member-of:group-3000]
。然后您将查询 GSIcan-access:item-1111
并返回[user-0002, group-1000]
. 比较这两个结果,您会发现user-0001
可以item-1111
通过group-1000
.
此模型的另一个好处是它足够灵活,可以处理其他权限用例。以下是该数据可能是什么样子的示例:
entity | relationship
===========================================
user-0001 | admin-of:group-1000
user-0001 | member-of:group-1000
user-0002 | member-of:group-2000
user-0002 | owner-of:item-1111
group-1000 | can-write:item-1111
group-1000 | can-read:item-1111
group-2000 | can-read:item-1111
Run Code Online (Sandbox Code Playgroud)
在这个例子中,我们也有可以管理组的用户,我们分离了项目的读写权限,我们可以定义一个用户或组作为一个项目的所有者(这可能意味着他们可以修改谁拥有读取或写入项目的权限)。
一个警告是,这假设组不能嵌套。如果组可以嵌套,那么您将需要更多查询来遍历嵌套组的层次结构,并且最好使用 AWS Neptune 或其他数据库来存储您的权限。
归档时间: |
|
查看次数: |
875 次 |
最近记录: |