我的简单数据模型： 用户可以创建Articles，这使他们成为这个特定Articles对象的Owner . 用户还可以邀请其他用户为其文章投稿，这使得其他用户 此特定文章的贡献者。
所以，有角色 Owner 和 Contributor，还有资源 Article
现在我的问题是，您将如何最好地使用 ZF2 的 ACL 和 BjyAuthorize 来实现这个构造？我在这里挣扎，因为 Users 的角色对于资源 Article 不是全局有效的，而是必须分配给单个 >文章实例。
【问题讨论】：
标签： zend-framework2 user-roles bjyauthorize
一般情况
我认为，ZF2 ACL 的优势在于根据角色结构继承权限，并且存在 ACL 感知模块，例如 MenuHelper。
如果您不需要继承或这些其他 - ACL 感知 - 模块，您可以创建一个非常简单的解决方案而无需 ACL 模块。
解决方案 1. - ACL
资源、角色和权限只是数据。因此，角色的含义取决于您在数据库中作为角色存储的内容，或者在创建授权结构时作为角色输入的内容。
Acl 对象的 isAllowed 方法也只是基于您创建的数据结构（角色、资源和权限）的验证，您可以决定如何处理这些信息。
- 我认为 - 你需要的是对象访问控制机制 [此用户/用户组（= 角色）写入/读取（= 特权）此特定对象（= 资源）] 除了功能访问控制 [可以这个用户/用户组（=角色）写/读（=特权）这种对象（=资源）]。
因此，如果您将文章存储为资源，将方法（写入、读取、删除等）连接为特权，并为给定的用户/组创建与这些特权的关系，您就实现了目标。
解决方案 2. - 带断言的 ACL
如果您在文章中存储了一个贡献者用户数组，您可以在创建“允许结构”时将此数组中的待检查用户的存在用作断言。
解决方案 2.1。 - 带有断言的 ACL - 在单独的表中
您可以将贡献者存储在单独的表中，并与文章表连接。
解决方案 3. - 贡献者序列化数组
如果您不需要 ZF2 ACL 的强大背景，您可以简单地检查文章中存储的贡献者数组中用户的存在。
我更喜欢解决方案 1. 的集中管理空调，但我也看到解决方案 2. 方面的优点。 （解决方案 1. 混合角色和用户定义，但我已经看到了组和用户对象的混合，所以这不会让我很困扰。:)）
上市文章
还需要考虑另一件事：列出文章，可以编辑（贡献者）。 使用 foreach 检查所有文章总是存在的。使用更多/更少的直接数据库查询会破坏 ZF2 ACL 理念。如果你也需要分页......那是个问题。 :)
还有很多其他解决方案（以及它们的组合）。要找到合适的，您还必须考虑文章的数量。如果您将每篇文章的每个贡献者的行存储在角色/资源/权限表中，它们会增长得非常快。
【讨论】：