Zend_ACL：如何为多个小团队设计基于角色的 ACL？
基于角色的 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 部分获取。这样可以在不更改代码的情况下添加新团队。这是正确的方法吗？
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
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里是一个相当闲聊的答案，只有松散的讨论，没有代码，至少目前是这样。
您自己的模型/数据结构必须考虑成员、位置和团队。我认为您已经非常清楚地描述了这些关系，所以应该很简单。关联思考：团队成员（包括经理）的表格；位置表；一个用于团队的表，具有用于位置的外键和用于识别经理的成员的外键；将成员与团队联系起来的交叉引用表。我假设您的成员模型将具有
isManagerOfTeam($team)、isMemberOfTeam($team)等方法。非常简单。但其中大部分只是对关系进行建模，可以说与访问控制无关。
对于访问控制来说，位置似乎是无关紧要的；团队成员和团队管理才是关键。
听起来您尝试访问控制的数据（最终将成为“资源”）将被标记为成员 ID，以识别“拥有”成员。因此，该数据的模型可能有一个方法
getMember()甚至只是getMemberId()。因此，我看到一些 Acl 规则使用
Zend_Acl_Assert_Interface实例对角色 ($member) 和这些资源之间的关系进行动态检查：然后是
assert()方法可以调用传递的角色和资源上的相关模型方法来检查团队和管理关系。就像我说的，有点松散的答案，但希望它能对一些想法有所帮助。
Kind of a fairly chatty answer here, loose discussion only, no code, at least for now.
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.
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 justgetMemberId().So I see some Acl rules that use a
Zend_Acl_Assert_Interfaceinstance to make dynamic examinations on the relationships between the role ($member) and those resources: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.