如何在 Zend Acl 中实现资源之间的多重继承？
长话短说：为什么 Zend ACL 支持角色而不是资源之间的多重继承？
我有一个很大的资源树，我希望能够对其授予权限。 过去，我所做的就是创建两棵不同的树来表示这一点。 第一个具有树中每种类型的通用资源。 第二个具有这些类型的所有实例，以相同的方式排列。 这意味着如果您要叠加树木，您会在同一级别上找到相同类型的对象。 然后，每个对象实例被设置为将第一棵树中的通用对象作为附加父对象。 这允许我为每种类型的对象设置默认权限，因此每个实例都将继承它们，而不必定义它们，但仍然为我提供了对每个实例的精细、特定的访问权限。
示例：
一个网站有 3 个模块： 用户，存储用户配置文件和其他内容的地方。 论坛，对当前问题进行热烈讨论 画廊，用户可以在其中上传宠物的照片
因此，上面提到的泛型树将如下所示：
module
/ | \
user forum gallery
/ | \
profile topic photo
|
post
实例树将如下所示：
module_1
/ / / | \ \
user1 user2 user3 forum gallery1 gallery2
| | | / \ / \ / \
profile profile profile sub1 sub2 photo photo photo photo
| / \
post1 post2 post3
在 ACL 中，每个用户对象实例将从第一棵树中的用户继承。 因此，默认情况下，我想让所有内容都可读，因此我允许在模块上读取。 一切都继承自模块，所以一切都很好。 我还希望用户能够编辑他们的个人资料，因此我授予每个用户对其各自个人资料的编辑权限，泛型树在这里没有帮助。 假设我的照片库是 NSFW，所以我想拒绝阅读它们。 通过多重继承，我可以拒绝任何未注册用户读取照片，这只是一项操作。 如果没有多重继承，我必须仔细检查每张照片并拒绝未注册用户的读取权限。 如果我有很多照片，这就是坏消息。
有谁知道如何做到这一点？ 它提供了我能想到的最灵活的解决方案。 如果您能想到更好的可以使用 Zend_Acl 实现的东西，也请回复！
非常感谢。
Long story short: why does Zend ACL support multiple inheritance among roles and not resources?
I have a large tree of resources that I would like to be able to grant permissions on. In the past, what I have done to represent this is creating two different trees. The first one has a generic resource of each type in a tree. The second has all the instances of these types, arranged in the same manner. It would mean that if you were to super impose the trees you would find objects of the same type on the same level. Then, each object instance is set to have it's generic object from the first tree as an additional parent. This allows me to set default permissions for every type of object, so each instance will inherit them instead of me having to define them, but still gives me refined, specific access to each instance.
An example:
A site has 3 modules:
users, where user profiles and whatnot are stored.
forums, where lively discussions about current issues take place
galleries, where users can upload photos of their pets
So, the generics tree mentioned above would look like this:
module
/ | \
user forum gallery
/ | \
profile topic photo
|
post
And the instances tree would look like this:
module_1
/ / / | \ \
user1 user2 user3 forum gallery1 gallery2
| | | / \ / \ / \
profile profile profile sub1 sub2 photo photo photo photo
| / \
post1 post2 post3
And in the ACL each user object instance would inherit from user in the first tree. So be default I want to make everything readable, so I allow read on module. Everything inherits from module, so it's all good. I also want users to be able to edit their profiles, so I grant edit to each user on their respective profile, the generics tree doesn't help here. Lets say my photo galleries are NSFW, so I want to deny read on them. With multiple inheritance, I can deny read on photo for any unregistered user, which is only one operation. Without multiple inheritance, I have to go through every photo and deny unregistered user the read privilege. If I have a lot of photos, this is bad news.
Does anyone know a way to do this? It provides the most flexible solution I can think of. If you can think of something better that can be implemented using Zend_Acl, please reply also!
Thanks very much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，回答你的问题。 资源的多重继承。 Zend_ACL 不支持这一点，因为您的资源树旨在复制您正在保护的物理资源。 例如，您根本不能让一个文件存在于多个父目录中。
因此，为了向您提供解决方案...
我假设您的“泛型”树是您的资源。
您的角色应该代表您的用户组，例如匿名、注册、版主、管理员等。每个更宽松的角色都应该继承前一个角色，因此“注册”将从“匿名”继承，“版主”从“注册”等继承这允许每个级别拥有其父级别的所有权限，然后添加一些权限。
假设您使用我所描述的结构，您还可以使用权限来分配可能的用户操作。 IE。 “查看”、“编辑”、“添加”和“管理”请参见 链接文本
您需要为“模块”上的匿名角色分配“查看”权限，从而向每个人授予读取权限。
您需要为“论坛”上的注册角色分配“添加”权限，从而为注册用户授予读取（继承自匿名角色）和添加权限。
您需要为“图库”上的注册角色分配“添加”权限，从而为注册用户提供读取（再次继承）和添加权限。
为版主、管理员等冲洗并重复。
要允许用户修改自己的个人资料、图像上传等，您不会使用 ACL 来处理此级别的交互。 只需在表示资源的任何对象（图像对象、配置文件对象等）上创建一个 isOwner 方法，该方法将根据当前登录的用户是否拥有该项目返回一个布尔值。 这样您就可以决定是否允许该用户编辑/删除/等该个人资料/图像。
希望这有用！
Firstly, to answer you question re. multiple-inheritance of resources. Zend_ACL does not support that because your resources tree is designed to replicate the physical resources you are protecting. You simply can't have (for example) a file present in more than one parent directory.
So to provide you with a solution...
I assume your 'generics' tree is your resources.
Your roles should represent your user groups, so anonymous, registered, moderators, admins etc. Each more permissive role should inherit from the previous, so 'registered' would inherit from 'anonymous', 'moderators' from 'registered' etc. This allows each level to have all the rights of it's parent and then add some.
Assuming you use a structure like I have described, you would also use a privilege to assign the possible user actions. ie. 'view', 'edit', 'add' and 'manage' see link text
You need to assign 'view' rights to the anonymous role on 'module', there by giving read access to everyone.
You need to assign 'add' rights to the registered role on 'forum', there by giving both read (inherited from the anonymous role) and add to registered users.
You need to assign 'add' rights to the registered role on 'gallery', there by giving both read (again inherited) and add to registered users.
Rinse and repeat for moderators, admins etc etc.
To allow a user to modify their own profile, image uploads etc. you would not use ACL to handle interactions at this level. Simply create an isOwner method on any objects that represent resources (Image object, Profile object, etc) that will return a boolean based on whether the currently logged in user owns that item. This way you can then decide whether or not to allow that user to edit / delete / etc. that profile / image.
Hope this is useful!
我不能直接从经验中推荐任何东西，很久以前我就使用每个资源的多个权限以困难的方式完成了这件事，这有点痛苦。
如果我现在正在编写 ACL 代码，我可能会查看这篇关于 ACL 资源类型的文章 http://codeutopia.net/blog/2009/02/11/zend_acl-part-2- Different-roles-and-resources -more-on-access/ 或许还有第 1 部分和第 3 部分以获取灵感。
在文章的最后，讨论了允许对所有资源进行读取访问并创建全面的允许/拒绝规则。
I can't recommend anything directly from experience, I've done it the hard way a long time ago using several permissions per resource and it was a bit painful.
If I was writing ACL code now I'd probably take a look at this article on ACL resource types at http://codeutopia.net/blog/2009/02/11/zend_acl-part-2-different-roles-and-resources-more-on-access/ and perhaps parts 1 and 3 for inspiration.
Towards the end of the article there's talk of allowing read access across all resources and creating blanket allow/deny rules.