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 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
-~----------~----~----~----~------~----~------~--~---
