如何设计基于角色的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部分获取。这样可以在不改变代码的情况下添加新团队。这是正确的方法吗?
答案 0 :(得分:3)
这里有一个相当健谈的答案,只是松散的讨论,没有代码,至少现在。
您自己的模型/数据结构必须考虑成员,位置和团队。我认为你已经非常清楚地描述了这种关系,所以这应该是直截了当的。关系思考:团队成员的表格,包括经理;地点表;用于将外键放入位置的团队的表格,以及用于识别经理的成员的外键;将成员链接到团队的交叉引用表。我假设您的成员模型将包含isManagerOfTeam($team)
,isMemberOfTeam($team)
的方法,类似的东西。很简单。
但其中很大一部分只是对关系建模,可以说与访问控制无关。
对于访问控制,似乎位置无关紧要;它是团队会员和团队管理的关键。
这听起来像你试图访问的数据 - 控制(最终将是'资源')将被标记为成员ID,标识“拥有”成员。因此,该数据的模型可能有方法getMember()
,甚至只有getMemberId()
。
所以我看到一些使用Zend_Acl_Assert_Interface
实例的Acl规则对角色($ member)和这些资源之间的关系进行动态检查:
然后assert()
方法可以调用传递的角色和资源上的相关模型方法来检查团队和管理关系。
就像我说的那样,是一种宽松的答案,但希望它有助于一些想法。