I wrote a workaround on my blog http://www.aviblock.com/blog/2009/03/19/acl-in-zend-framework/#comments
On Sun, Jun 14, 2009 at 5:54 AM, Mon Zafra <[email protected]> wrote: > 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 >>> >>> >>> >>> >> >
