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 this case, the general permission on the Controller seems to
> >>>>>>>> override the explicitly forbidden Action.
>
> >>>>>>>> $ cake acl grant deceze Users all
> >>>>>>>> $ cake acl deny deceze Users/delete all
>
> >>>>>>>> $ cake acl check deceze Users/delete all
> >>>>>>>> deceze is allowed.
>
> >>>>>>>> Is this by design or a bug?
>
> >>>>>>>> Chrs,
> >>>>>>>> Dav
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
