I have just updated the ticket with something that appears to solve
the problem.
At least the solution now allows the test case to pass. And in my own
application, things seem to be working out correctly.
But the logic of these inheritance trees gets pretty tricky, so I
wouldn't be surprised if I missed something in my solution.
Check it out, and see if it works for you as well.
Since the solution relies on lft and rght values, it will work no
matter what order the ACO and ARO nodes were created in.
-Aran
On Apr 9, 9:10 pm, David Christopher Zentgraf <[EMAIL PROTECTED]>
wrote:
> I'm currently trying to figure out the best way of dealing with rather
> complex ACLs myself...
>
> I have different "modules" (controllers) in my application, and while
> a user may be allowed to administer one module, he might be very
> restricted in another. So I either have to be able to set very
> specific permissions on a per-action basis for each user, or I have to
> be able to assign a user to more than one group. The latter is not
> possible with the current Cake ACL system, and the former only works
> with restrictions... :-/
>
> On 10 Apr 2008, at 12:41, aranworld wrote:
>
>
>
> > Thanks for the clarification. That does make sense to me.
>
> > I didn't notice the problem, because I am using the following in my
> > app_controller.php to solve the same problem. I will admit is not the
> > most elegant solution, but it does work:
>
> > function beforeFilter() {
> > $this->Auth->allowedActions = array('index', 'view', 'display');
> > $this->checkAuth();
> > }
>
> > In controllers where I want to be more restrictive, I override this
> > function.
>
> > On Apr 9, 7:39 pm, "David Zentgraf" <[EMAIL PROTECTED]> wrote:
> >> Thanks aranworld, saw your message just now.
>
> >> I think the use case is when you're not using groups, and you have a
> >> lot of children. In that case it's a lot easier to generally allow
> >> access to the parent, but deny access to a few selected children, for
> >> example.
>
> >> Additionally it's just expected behaviour IMHO.
> >> If I explicitly state
> >> $ cake acl deny deceze Users/delete all
>
> >> then
> >> $ cake acl check deceze Users/delete all
>
> >> should never yield an Allowed.
>
> >> On Thu, Apr 10, 2008 at 3:50 AM, aranworld <[EMAIL PROTECTED]>
> >> wrote:
>
> >>> The idea of basing inheritance on id order is really not going to
> >>> work, because over the course of usage, ACO nodes are bound to be
> >>> added in a non-linear fashion. This is why lft and rght values are
> >>> used instead to determine inheritance.
>
> >>> I am able to reproduce this bug as described.
>
> >>> However, if you have the following:
>
> >>> ======
> >>> ACO Table
>
> >>> Site
> >>> ---Articles
>
> >>> ======
>
> >>> ARO Table
>
> >>> Users
> >>> ---Frank
>
> >>> ======
>
> >>> And you do:
>
> >>> cake acl grant Users Site delete
> >>> cake acl deny Frank Articles delete
>
> >>> Then you get the following
>
> >>> cake acl check Users Articles delete
> >>> Users are allowed
>
> >>> cake acl check Frank Articles delete
> >>> Frank is not allowed
>
> >>> The issue only seems to apply to situations in which the overlapping
> >>> permissions are from the same ARO node. I'm not sure this is
> >>> going to
> >>> be considered buggy behavior by the developers.
>
> >>> Instead, it seems like the framework is set up so that parent
> >>> permissions override child permissions when the same user is
> >>> involved. As long as I understand that this is the behavior in
> >>> play,
> >>> then I think I can live with things as is.
>
> >>> But maybe I'm not thinking of the situation in which you would
> >>> want to
> >>> give a user ALL permissions on parent node and then try to deny a
> >>> permission on a subnode?
>
> >>> On Apr 8, 11:34 pm, David Christopher Zentgraf <[EMAIL PROTECTED]>
> >>> wrote:
>
> >>>> Ignore my previous fix, only works under certain conditions.
> >>>> This fix is more robust:
>
> >>>> Insert:
> >>>> // ======= WORKAROUND =========
> >>>> $perms = Set::sort($perms, '{n}.Aco.id', 'desc');
> >>>> // =============================
>
> >>>> before:
> >>>> $perms = Set::extract($perms, '{n}.' . $this->Aro->Permission-
> >>>> >alias);
>
> >>>> The checking algorithm still needs some revisitation.
>
> >>>> On 9 Apr 2008, at 13:15, David Christopher Zentgraf wrote:
>
> >>>>> Posted a possible fix inhttps://trac.cakephp.org/ticket/4450.
>
> >>>>> Replace the loop on line 313 of cake/libs/controller/components/
> >>>>> acl.php:
>
> >>>>> foreach ($perms as $perm) {
> >>>>> // The inner part stays, only the enclosing loop can go!
> >>>>> }
>
> >>>>> with:
>
> >>>>> $perm = $perms[count($perms) - 1];
>
> >>>>> Feedback would be appreciated.
>
> >>>>> On 9 Apr 2008, at 11:56, David Christopher Zentgraf wrote:
> >>>>>> Tried with the latest Nightly (08.04.08), dumped all my tables,
> >>>>>> set everything up again, still the same.
> >>>>>> Opened a ticket for it:https://trac.cakephp.org/ticket/4450
>
> >>>>>> On 8 Apr 2008, at 22:23, Dardo Sordi Bogado wrote:
>
> >>>>>>> It's looks exactly as the bug described.
>
> >>>>>>> Look in cake/libs/controller/components/acl.php
>
> >>>>>>> method check,
>
> >>>>>>> look for === -1, change to == -1. If it isn't there,
> >>>>>>> probably you
> >>>>>>> need to put a couple of pr() and start debugging :(.
>
> >>>>>>> Before that, try with an fresh install of the latest svn.
>
> >>>>>>> On Tue, Apr 8, 2008 at 9:12 AM, David Christopher Zentgraf
>
> >>>>>>> <[EMAIL PROTECTED]> wrote:
>
> >>>>>>>> SELECT `Aro`.`id`, `Aro`.`parent_id`, `Aro`.`model`,
> >>>>>>>> `Aro`.`foreign_key`, `Aro`.`alias` FROM `aros` AS `Aro` LEFT
> >>>>>>>> JOIN
> >>>>>>>> `aros` AS `Aro0` ON (`Aro`.`lft` <= `Aro0`.`lft` AND
> >>>>>>>> `Aro`.`rght`
> >>>>>>>>> =
> >>>>>>>> `Aro0`.`rght`) WHERE `Aro0`.`model` = 'User' AND
> >>>>>>>> `Aro0`.`foreign_key`
> >>>>>>>> = 3 ORDER BY `Aro`.`lft` DESC
>
> >>>>>>>> SELECT `Aco`.`id`, `Aco`.`parent_id`, `Aco`.`model`,
> >>>>>>>> `Aco`.`foreign_key`, `Aco`.`alias` FROM `acos` AS `Aco` LEFT
> >>>>>>>> JOIN
> >>>>>>>> `acos` AS `Aco0` ON (`Aco0`.`alias` = 'Users') LEFT JOIN
> >>>>>>>> `acos` AS
> >>>>>>>> `Aco1` ON (`Aco1`.`lft` > `Aco0`.`lft` AND `Aco1`.`rght` <
> >>>>>>>> `Aco0`.`rght` AND `Aco1`.`alias` = 'index') WHERE
> >>>>>>>> ((`Aco`.`lft` <=
> >>>>>>>> `Aco0`.`lft` AND `Aco`.`rght` >= `Aco0`.`rght`) OR
> >>>>>>>> (`Aco`.`lft` <=
> >>>>>>>> `Aco1`.`lft` AND `Aco`.`rght` >= `Aco1`.`rght`)) ORDER BY
> >>>>>>>> `Aco`.`lft`
> >>>>>>>> DESC
>
> >>>>>>>> SELECT `Permission`.`id`, `Permission`.`aro_id`,
> >>>>>>>> `Permission`.`aco_id`, `Permission`.`_create`,
> >>>>>>>> `Permission`.`_read`,
> >>>>>>>> `Permission`.`_update`, `Permission`.`_delete`, `Aro`.`id`,
> >>>>>>>> `Aro`.`parent_id`, `Aro`.`model`, `Aro`.`foreign_key`,
> >>>>>>>> `Aro`.`alias`,
> >>>>>>>> `Aro`.`lft`, `Aro`.`rght`, `Aco`.`id`, `Aco`.`parent_id`,
> >>>>>>>> `Aco`.`model`, `Aco`.`foreign_key`, `Aco`.`alias`, `Aco`.`lft`,
> >>>>>>>> `Aco`.`rght` FROM `aros_acos` AS `Permission` LEFT JOIN
> >>>>>>>> `aros` AS
> >>>>>>>> `Aro` ON (`Permission`.`aro_id` = `Aro`.`id`) LEFT JOIN
> >>>>>>>> `acos` AS
> >>>>>>>> `Aco` ON (`Permission`.`aco_id` = `Aco`.`id`) WHERE
> >>>>>>>> `Permission`.`aro_id` = 6 AND `Permission`.`aco_id` IN (4, 3,
> >>>>>>>> 2)
>
> >>>>>>>> The result of that last call even looks pretty good to me:
>
> >>>>>>>> +----+--------+--------+---------+-------+---------+---------
> >>>>>>>> +------
> >>>>>>>> +-----------+-------+-------------+--------+------+------
> >>>>>>>> +------
> >>>>>>>> +-----------+-------+-------------+-------+------+------+
> >>>>>>>> | id | aro_id | aco_id | _create | _read | _update | _delete |
> >>>>>>>> id |
> >>>>>>>> parent_id | model | foreign_key | alias | lft | rght | id |
> >>>>>>>> parent_id | model | foreign_key | alias | lft | rght |
> >>>>>>>> +----+--------+--------+---------+-------+---------+---------
> >>>>>>>> +------
> >>>>>>>> +-----------+-------+-------------+--------+------+------
> >>>>>>>> +------
> >>>>>>>> +-----------+-------+-------------+-------+------+------+
> >>>>>>>> | 1 | 6 | 3 | 1 | 1 | 1 | 1
> >>>>>>>> | 6
> >>>>>>>> | NULL | User | 3 | deceze | 11 | 12 | 3
> >>>>>>>> | 2 | NULL | NULL | Users | 2 | 13 |
> >>>>>>>> | 3 | 6 | 4 | -1 | -1 | -1 | -1
> >>>>>>>> | 6
> >>>>>>>> | NULL | User | 3 | deceze | 11 | 12 | 4
> >>>>>>>> | 3 | NULL | NULL | index | 3 | 4 |
> >>>>>>>> +----+--------+--------+---------+-------+---------+---------
> >>>>>>>> +------
> >>>>>>>> +-----------+-------+-------------+--------+------+------
> >>>>>>>> +------
> >>>>>>>> +-----------+-------+-------------+-------+------+------+
> >>>>>>>> 2 rows in set (0.00 sec)
>
> >>>>>>>> And just for completeness:
>
> >>>>>>>> $ cake acl view aco
>
> >>>>>>>> ---------------------------------------------------------------
> >>>>>>>> Aco tree:
> >>>>>>>> ---------------------------------------------------------------
> >>>>>>>> [2]ROOT
>
> >>>>>>>> [3]Users
>
> >>>>>>>> [4]index
>
> >>>>>>>> [5]edit
>
> >>>>>>>> [6]register
>
> >>>>>>>> [7]profile
>
> >>>>>>>> [8]delete
>
> >>>>>>>> But:
>
> >>>>>>>> $cake acl check deceze Users/index all
> >>>>>>>> deceze is allowed.
>
> >>>>>>>> On 8 Apr 2008, at 20:49, Dardo Sordi Bogado wrote:
>
> >>>>>>>>> Can you post the SQL generated?
>
> >>>>>>>>> On Tue, Apr 8, 2008 at 8:47 AM, David Christopher Zentgraf
>
> >>>>>>>>> <[EMAIL PROTECTED]> wrote:
>
> >>>>>>>>>> Those URLs are not loading for me right now,
> >>>>>>>>>> but I'm experiencing this on a Nightly from April 5th (I
> >>>>>>>>>> think).
>
> >>>>>>>>>> cake/libs/controller/components/acl.php:
> >>>>>>>>>> /* SVN FILE: $Id: acl.php 6491 2008-03-01 03:12:12Z nate $ */
> >>>>>>>>>> ...
>
> >>>>>>>>>> On 8 Apr 2008, at 20:17, Dardo Sordi Bogado wrote:
>
> >>>>>>>>>>> Bug #3851,
>
> >>>>>>>>>>>https://trac.cakephp.org/ticket/3851
> >>>>>>>>>>>https://trac.cakephp.org/changeset/6342
>
> >>>>>>>>>>> It's fixed in current versions.
>
> >>>>>>>>>>> On Tue, Apr 8, 2008 at 6:01 AM, David Christopher Zentgraf
>
> >>>>>>>>>>> <[EMAIL PROTECTED]> wrote:
>
> >>>>>>>>>>>> Hi,
>
> >>>>>>>>>>>> Am I getting this right? With the ACL component, AROs
> >>>>>>>>>>>> inherit
> >>>>>>>>>>>> their
> >>>>>>>>>>>> permissions like this:
>
> >>>>>>>>>>>> Group [denied something]
> >>>>>>>>>>>> |- User [allowed something]
>
> >>>>>>>>>>>> In this case, the explicitly granted permission on the User
> >>>>>>>>>>>> overrides
> >>>>>>>>>>>> the general Group setting, allowing the User something
> >>>>>>>>>>>> specifically.
> >>>>>>>>>>>> With ACOs the opposite seems to be the case:
>
> >>>>>>>>>>>> Controller [allowing user]
> >>>>>>>>>>>> |- Action [denying user]
>
> >>>>>>>>>>>> In
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
