Description

Zend_Acl::isAllowed currently transforms any is_a Zend_Acl_Role_Interface and Zend_Acl_Resource_Interface based objects to that of Zend_Acl_Role, and Zend_Acl_Resource.

This diminishes any benefit a developer might see in using assertions in a dynamic manner (ie, accessing properties of an object that has implemented a Role or Resource Interface) inside the assertion.

The issue description shows the same code as Zend_Acl already has at the top of isAllowed().

The proposed fix has no effect since: * Zend_Acl_Role_Registry::get() always returns an instance of Zend_Acl_Role_Interface unless an exception is thrown for a role not found, and * Zend_Acl::get() always returns an instance of Zend_Acl_Resource_Interface unless an exception is thrown for a resource not found.

Resolving as incomplete. See also [ZF-1722] and [ZF-1765].

Posted by Ralph Schindler (ralph) on 2007-08-01T13:41:10.000+0000

Darby, the problem with ACL at current is its goals and architecture. The impression is that by using a is-a (instanceof) architecture, you are implying that you can implement Base Roles and Resoures and expect them to persist through the isAllowed, which is not the case. The initial problem is that isAllowed will take any supplied object that implements the interface, and turn it into the object presented at ACL creation time.

This is not what I want, and I think that moving forward, as more people start to use ACL for runtime resource access checking, this will be a need.

Will allow an object that implements the interface to persist through the isAllowed, as long as the ID (object type) matches somethign that is in the ACL registry.

Again, its an architectual issue, but one that I will address in a few days with code.

Posted by Ralph Schindler (ralph) on 2007-08-03T12:37:24.000+0000

After discussion with darby, this is still an issue. (linked to ZF-1722 as well)

Posted by Martijn Korse (themarty) on 2008-08-08T06:08:39.000+0000

If i understand the problem correctly i think this shouldn't be solved here, but by overloading the _getRoleRegistry() and get() method.

I've created something in the past where i extended the Role Registry class and overloaded the getRoleRegistry() method (in an extended version of the Zend_Acl class), so it would return an object of my own registry class. and had no problem accessing the the properties of my custom role objects in assertions

Posted by Wil Sinclair (wil) on 2008-12-19T11:32:31.000+0000

I think you're the right person to assign this to, Ralph. We don't need to address it immediately, but I'd like closure on this soon after 1.8.

Posted by Avi Block (blocka) on 2009-05-02T20:46:26.000+0000

Any update on this? 1.8 has been released!

Posted by Stefan Gehrig (sgehrig) on 2009-06-15T01:55:37.000+0000

Anything new on this one?

Posted by James Ellis (jamesellis) on 2009-06-16T06:41:25.000+0000

Is Ralph actually working on this issue actively or should we not hold our breath?