CakePHP ACL：是否需要基础组/ARO
我正在为我的 CakePHP 应用程序 (1.3.14) 实现 ACL 组件。我已经正确设置了所有内容，但有一些地方我仍然模糊。
主要是，我是否需要为特殊的基本用户组（ARO）显式设置权限（ACO）？
为简单起见，假设我有管理员，然后是其他人（普通用户）。那么我是否需要为这些普通用户创建一个组并映射他们的所有允许权限？随着应用程序的发展，这些权利的管理似乎永远不会结束。
另外，将用户分配到多个组怎么样？
理想情况下，如果一个人拥有用户帐户，则身份验证组件将授予对整个系统的访问权限。然后，ACL 将简单地拒绝他们进入受现有组保护的部分。
看来ACL和Auth的耦合度太高了。但这可能是我新的（有限的）理解。任何澄清将不胜感激。
更新
我已经开始赏金。总之，我想实现 CakePHP ACL（最好，但匹配的第三方组件也是可以接受的）来满足/解决以下问题：
- 将用户分配到多个组
- 轻松维护“公共”用户组 - 不必不断添加一般用户可以访问的控制器/操作
- 管理对控制器/访问的访问的代码示例
- 正确测试用户所属组的代码示例。
I'm implementing the ACL component for my CakePHP app (1.3.14). I have everything setup correctly, but there are a few areas where I'm still fuzzy.
Mainly, do I need to explicitly set rights (ACOs) for a special base user group (AROs)?
For simplicity, let's say I have Administrators and then everyone else (general users). So do I need to create a group for these general users and map all their allow rights? Seems like management of these rights would be never ending as the app grew.
Also, what about assigning users to multiple groups?
Ideally if a person had a user account the Auth component would grant access to the system as a whole. Then ACL would simply deny them from the sections that were protected by an existing group.
It seems like the coupling of ACL and Auth is too high. But it may be my new (limited) understanding. Any clarification would be greatly appreciated.
UPDATE
I've started a bounty. In summary, I want to implement CakePHP ACL (preferably, but a matching third-party component is acceptable) that meets/addresses the following:
- Assign users to multiple groups
- Easily maintain a "public" user group - don't have to constantly add the controllers/actions a general user can access
- Code example of managing access to a controller/access
- Code example of properly testing a user belongs to a group.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为使用 Cake 的本机 ACL 实现的最佳效果如下所示：
（以上全部通过 cake shell 完成，但很容易转换为 PHP 变体）
基本上，您可以要么使用“默认拒绝”范例（如 Cake 自己的 ACL 教程中所示），要么使用上面的“默认允许”范例。无论您选择哪种方法，都取决于您期望应用程序的增长方式：您的大多数控制器是公开的，只有少数限制为管理员，还是您的大多数应用程序将受到公共限制，并在需要时给予特定访问权限？无论哪种方式，您仍然需要授予或拒绝访问权限。
请注意在 root 下创建的两个 ARO：public 和 registered。使用此模型，在创建 ARO 树时将已注册视为根 - 将所有“真实用户”组放在其下面。这样，您就可以像平常一样对注册下的对象使用ACL，并且公共用户将存在于该对象之外。
尽管如此，没有什么可以阻止您使用 Cake 的身份验证机制并滚动您自己的访问控制方法。这是一个示例： 简单身份验证和授权申请。 （注意：这是为 CakePHP 2.0 编写的，但这些概念也适用于 1.3）。
编辑-
重新阅读问题和其他回复后，我意识到您的目标更多是基于角色的访问控制模型，而不是内置的传统的每用户一个模型ACL 组件。以下是扩展 RBAC 内置身份验证组件的几个示例：
此外，这篇由两部分组成的文章描述了一种可应用于 Cake 应用程序的数据库支持的基于角色的授权方法。
I think the best you can hope for using Cake's native ACL implementation is something like the following:
(the above is all done through the cake shell, but is easily translated to the PHP variant)
Basically, you can either use a "default-deny" paradigm (as demonstrated in Cake's own ACL tutorial), or a "default-allow" paradigm as above. Whichever method you choose will depend on how you expect the application to grow: will most of your controllers be public with only a select few restricted to Administrators, or will most of your application be restricted with Public given specific access where needed? Either way, you still need to either grant or deny access.
Notice the two AROs created under root: public and registered. With this model, treat registered as if it were root when creating your ARO tree -- put all of your "real user" groups underneath it. That way, you can use ACL as normal on the objects under registered, and the public users will exist outside of that.
All that said, there's nothing stopping you from using Cake's authentication mechanism and rolling your own access control method. Here's an example: Simple Authentication and Authorization Application. (NOTE: This is written for CakePHP 2.0, but the concepts apply to 1.3 as well).
EDIT -
After re-reading the question and the other responses, I realized you're aiming more for a role-based access control model rather than the traditional one-aro-per-user model of the builtin ACL component. Here are a couple of examples of extending the built-in auth component for RBAC:
Also, this two-part article describes an approach to database-backed role-based authorization that can be applied to your Cake application.
您可以同时拥有 ACO 树和 ARO 树。在 ARO 树中，您将拥有 adminsGroup<-usersGroup。您需要为这些组设置权限。在 ACO 树中，您将有 baseACO<-subACO<-treeOfACOsForUsers。如果出现以下情况，您将不需要维护任何新 ACO：1) 用户组被允许使用 subACO，2) 任何新 ACO 都是 subACO 的子级。这个想法是组织一个 ACO 树，这样如果您允许访问父级，则所有子级都可以自动访问。您也可以拥有一个拒绝访问的分支。因此，您只需要维护（分配权限）靠近根的几个分支。
您可能有兴趣查看我的 PoundCake 控制面板 - 一个通过用户友好的 Web 界面实现 ACL 的插件（支持 CakePHP v1.3）。
更新：
这里是你需要什么。
You can have both ACOs tree and AROs tree. In the AROs tree you will have adminsGroup<-usersGroup. You will need to setup rights for these groups. In the ACOs tree you will have baseACO<-subACO<-treeOfACOsForUsers. You will not need to maintain any new ACOs if: 1) userGroups are allowed to use subACO, 2) any new ACO is a child of subACO. The idea is to organize a tree of ACOs, so that if you allow access to a parent all children are accessable automatically. You can have a branch with denied access also. So you will need to maintain (assigning permissions) only several branches close to the root.
You may be interested to look at my PoundCake Control Panel - a plugin implementing ACL with user friendly web interface (CakePHP v1.3 is supported).
UPDATE:
Here is what you need.