问题描述
应如何设计基于角色的 ACL:
How role based ACL should be designed for :
多个团队，每个团队由一名经理和多名成员组成，在一个地点工作.每个位置可以有多个团队，并且有多个位置.
Multiple teams, each team consisting of one manager and multiple members and working from one location. Each location could have multiple teams and there are multiple locations.
每个团队的经理只能查看/编辑其团队成员的数据.一个人也可以是多个团队的成员，与位置无关.
Manager of each team could only view/edit data for his team members. A person could also be member of multiple teams, independent of location.
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 部分获取数据.这样可以在不更改代码的情况下添加新团队.这是正确的方法吗?
My thought: I'm thinking of separating it in two parts. Part 1: There should be one group for each team. Maintain table of group membership in database. Part 2: Now, each user can have any role. And ACL could be designed based on those roles. But data would be fetched based on Part 1. this way new teams could be added without change in code. Is this a right way to go?
推荐答案
这里是一个相当健谈的答案，只是松散的讨论，没有代码，至少现在是这样.
Kind of a fairly chatty answer here, loose discussion only, no code, at least for now.
您自己的模型/数据结构必须考虑成员、位置和团队.我认为您已经非常清楚地描述了这些关系，所以这应该很简单.关系思考:团队成员(包括经理)的表格；位置表；一个团队表，外键指向位置，外键指向成员，识别经理；将成员与团队联系起来的交叉引用表.我假设您的成员模型将具有用于 isManagerOfTeam($team)、isMemberOfTeam($team) 之类的方法.非常简单.
Your own model/data structure has to consider members, locations, and teams. I think you have described the relationships pretty clearly, so that should be straightforward. Thinking relationally: a table for team members, including managers; a table for locations; a table for teams with a foreign key into locations and a foreign key into members identifying the manager; a cross-ref table linking members to teams. I assume your member model will have methods for isManagerOfTeam($team), isMemberOfTeam($team), stuff like that. Pretty straightforward.
但其中大部分只是对关系建模，可以说独立于访问控制.
But much of this is just modeling the relationships, arguably independent of access-control.
对于访问控制，似乎位置无关紧要；关键是团队成员和团队管理.
For access-control, it appears that location is irrelevant; it's team membership and team management that are the key.
听起来您尝试访问控制的数据(最终将成为资源")将被标记为成员 ID，标识拥有"成员.因此，该数据的模型可能有一个方法 getMember() 甚至只有 getMemberId().
It also sounds like the data you are trying to access-control (what will eventually be the 'resource') will be tagged with a member id, identifying the "owning" member. So, the model for that data might have a method getMember() or even just getMemberId().
所以我看到一些 Acl 规则使用 Zend_Acl_Assert_Interface 实例对角色($member)和这些资源之间的关系进行动态检查:
So I see some Acl rules that use a Zend_Acl_Assert_Interface instance to make dynamic examinations on the relationships between the role ($member) and those resources:
- My_Acl_Assertion_BelongsToSelf
- My_Acl_Assertion_BelongToMemberUnderManagement
然后 assert() 方法可以对传递的角色和资源调用相关的模型方法来检查团队和管理关系.
Then the assert() methods could call the relevant model methods on the passed role and resource to check the team and management relationships.
就像我说的，有点松散的答案，但希望它对一些想法有所帮助.
Like I said, kind of a loose answer, but hopes it helps with some ideas.
这篇关于Zend_ACL :如何为多个小团队设计基于角色的 ACL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！