0

基于角色的 ACL 应如何设计用于：

多个团队，每个团队由一名经理和多名成员组成，并在一个地点工作。每个位置可以有多个团队，并且有多个位置。

每个团队的经理只能查看/编辑其团队成员的数据。一个人也可以是多个团队的成员，与位置无关。

Location_1
-Team_1            -Team_2
 -Manager           -Manager
  -Member_1          -Member_1
  -Member_2          -Member_2

Location_2
-Team_1            -Team_2
 -Manager           -Manager
  -Member_1          -Member_1
  -Member_2          -Member_2

我的想法：我想把它分成两部分。第 1 部分：每个团队应该有一个小组。在数据库中维护组成员关系表。第 2 部分：现在，每个用户都可以拥有任何角色。并且可以根据这些角色设计 ACL。但是将根据第 1 部分获取数据。这样可以在不更改代码的情况下添加新团队。这是正确的方法吗？

4

1 回答 1

3

这里有一个相当健谈的答案，只有松散的讨论，没有代码，至少现在是这样。

您自己的模型/数据结构必须考虑成员、位置和团队。我认为您已经非常清楚地描述了这些关系，所以应该很简单。关联思考：团队成员（包括经理）的表格；位置表；具有外键到位置和外键到识别经理的成员的团队表；将成员链接到团队的交叉引用表。isManagerOfTeam($team)我假设您的成员模型将具有isMemberOfTeam($team)类似的方法。很简单。

但其中大部分只是对关系进行建模，可以说是独立于访问控制的。

对于访问控制，位置似乎无关紧要；团队成员和团队管理是关键。

听起来您尝试访问控制的数据（最终将成为“资源”）将被标记为成员 ID，标识“拥有”成员。因此，该数据的模型可能有一个方法getMember()，甚至只是getMemberId().

所以我看到一些 Acl 规则使用Zend_Acl_Assert_Interface实例对角色（$member）和这些资源之间的关系进行动态检查：

  1. My_Acl_Assertion_BelongsToSelf
  2. My_Acl_Assertion_BelongToMemberUnderManagement

然后assert()方法可以在传递的角色和资源上调用相关的模型方法来检查团队和管理关系。

就像我说的，有点松散的答案，但希望它有助于一些想法。

于 2011-05-08T07:18:00.143 回答