Ooops, read the date incorrectly. It's actually 23 months old :p

   -- Mon


On Sun, Jun 14, 2009 at 5:52 PM, Mon Zafra <[email protected]> wrote:

> That's how I expected assertions to work as well. Transforming the roles
> and resources into normal Zend_Acl_Role/Resource really limits the
> usefulness of assertions. This issue is exactly two years old now. There are
> some workarounds in http://framework.zend.com/issues/browse/ZF-1721 and
> related issues.
>
>    -- Mon
>
>
>
> On Sun, Jun 14, 2009 at 4:55 PM, Stefan Gehrig <[email protected]> wrote:
>
>> Dear all,
>>
>> I just started to use Zend_Acl for authorization in one of our projects
>> but
>> either I do have some real problem understanding the use of assertions or
>> there is some flaw in the assertion design.
>> I don't know if some other developers stumbled upon this issue - perhaps
>> it's just that I don't understand the purpose of assertion correctly.
>> Let's say, we have the following domain models:
>>
>> class App_User implements Zend_Acl_Role
>> {
>>        //...
>>
>>        public function getId()
>>        {
>>                return $this->_userId;
>>        }
>>
>>        public function getRoleId()
>>        {
>>                return $this->_group;
>>        }
>>
>>        //...
>> }
>>
>> class App_GameSheet implements Zend_Acl_Resource
>> {
>>        //...
>>
>>        public function getHomeTeamAdminId()
>>        {
>>                return $this->_homeTeamAdminId;
>>        }
>>
>>        public function getLeagueAdminId()
>>        {
>>                return $this->_leagueAdminId;
>>        }
>>
>>        public function getResourceId()
>>        {
>>                return __CLASS__;
>>        }
>>
>>        //...
>> }
>>
>> class App_Acl_GameSheetAssertion implements Zend_Acl_Assert_Interface
>> {
>>    public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface $role =
>> null,
>>        Zend_Acl_Resource_Interface $resource = null, $privilege = null)
>>    {
>>        if (($resource instanceof App_GameSheet) && ($role instanceof
>> App_User)) {
>>            $userId = $role->getId();
>>            $leagueAdmin = $resource->getLeagueAdminId ();
>>            $homeTeamAdmin = $resource->getHomeTeamAdminId ();
>>            if (in_array($userId, array($leagueAdmin, $homeTeamAdmin))) {
>>                return true;
>>            } else {
>>                return false;
>>            }
>>        }
>>        return null;
>>    }
>> }
>>
>> I though, I could do the following:
>>
>> $acl = new Zend_Acl();
>> $acl->addRole(new Zend_Acl_Role('editor'));
>> $acl->addRole(new Zend_Acl_Role('admin'), 'editor);
>> $acl->add(new Zend_Acl_Resource('App_GameSheet');
>> $acl->allow('admin', null, null, null);
>> $acl->allow('editor', 'App_GameSheet', null, new
>> App_Acl_GameSheetAssertion());
>>
>> $gameSheet = App_GameSheet::load(123);
>> $user = App_User::load(456);
>> var_dump($acl->isAllowed($user, $gameSheet, null));
>>
>> The problem now is that Zend_Acl changes $role and $resource to simple
>> Zend_Acl_Role and Zend_Acl_Resource objects before passing them into the
>> assertion.
>> Am I totally wrong in my understanding of how this should work? I
>> personally
>> think that the preceding solution would be a very elegant way to cope with
>> such issues.
>>
>> Should this be considered a bug or rather an idea for improvement (as this
>> surely would break BC it would have to wait until ZF 2.0 I assume)?
>> Is there any other workaround or design that solves this problem using
>> Zend_Acl? I really thought that I found the philosopher's stone for this
>> problem ;-)
>>
>> Thanks to all of you!
>>
>> Best regards
>>
>> Stefan
>>
>>
>>
>>
>

Reply via email to