【发布时间】：2018-04-22 01:20:55
【问题描述】：
我已经阅读了 ACL （访问控制列表），但我不明白使用它比 金字塔 有什么意义> 思维方式。 （Controller Admin 扩展了 Moderator，后者扩展了 User）。
最好的方法是什么？堆栈扩展是一种不好的做法吗？
【问题讨论】：
标签： php controller acl user-permissions
【发布时间】：2018-04-22 01:20:55
【问题描述】：
首先，身份验证。
这只是登录并断言username / password 组合与用户 X 相关。
二、授权。
第二个通常是事情变得更复杂的地方。但是对于大多数用例，您的一般理解是可以的。
Zend\Rbac 或 Zend\Acl 之类的包是在域逻辑中实施授权的良好起点。我更喜欢 RBAC，因为它涉及到更多的实现。阅读有关更细致入微的方法的内容。
使用 rbac，用户有一个角色 (admin)，该角色可以从主持人继承，也可以从用户继承。在 rbac 中，角色被授权做某事，而不是身份（user / principal 在其他语言中）。当您授权编辑 cmets 时，事情可能会变得棘手。只有所有者可以编辑他或她自己的 cmets (per-entity rules)。但版主可以编辑或删除任何人的 cmets。
在上面的包中，我为每个实体的授权使用了一个自定义编写的断言，因为这是在该包中处理它的一种非常简单的方法。或者，您可以有一个用户是客户 X 的管理员……但这并不意味着他们是客户 Y 的管理员。因此，您的规则可以非常复杂，而不仅仅是简单的层次结构。
在这些情况下，每个用户都可能与客户以及每个用户的相关角色建立多对多关系。
您的isAllowed 方法必须根据业务标准进行检查。这特定于您的域 - 这就是为什么授权策略因项目而异的原因。通常，当事情变得复杂时，就会发生这种情况。否则，大多数时候权限实际上并不太复杂。
【讨论】：
如果对象属于彼此并且具有父级“价值”，则堆叠扩展永远不会成为真正的问题。所以 Admin -> Moderator -> User -> Anonymous -> UserBase 适合授权分层。
但是正如 Giulio 已经提到的那样，这个实现在多个项目中是广泛且广泛不同的，一个人可以使用包或滚动自己的包（如果他们知道自己在做什么，否则使用预先存在的包会更安全，例如上面提到的）
【讨论】：