-- Patrick Veach <[EMAIL PROTECTED]> wrote
(on Friday, 25 May 2007, 03:25 PM -0500):
> Thank you for response. I really would like to have the api I mentioned.
> The current one is perfect for controller::action, but i think there is a
> need
> to be able to allow/deny at the modular level. There is a natural parental
> relationship between module::controller::action. This allows you to specify
> at each level exactly which resources are being allowed/denied.
>
>
>
> Here are some things that bother me with the current non-modular ACL.
>
> Modules may have controllers::actions with the same name. The
> indexController comes to
> mind. How do you ban some index::action and allow others?
>
> Attempts to solve the above problems (and others) lead to complicated tests
> at the use point.
> i.e. first test the module then test the controller::action. instead of a
> nice clean $acl->allow(...);
>
>
> I realize that the current ACL api isn't specific to the
> controller::action, but it does map onto the controller::action very
> nicely. With one more level of indirection it should map onto the
> module::controller::action.
Patrick -- maybe you might want to get creative in your usage of ACLs in
their current API. In my own code, I define the resource as the module,
and then define actions for the module. These are typically the
controller names (as usually the ACL's are either true for all actions
of the module or none at all), but if I need to define more finegrained
access, I use the controller.action notation, which is very easy to
check for.
While I understand your desire for a 1-to-1 relationship between the
Zend_Acl and the implementation of Zend_Controller, ACLs have a more
general usage than Zend_Controller -- they could easily also be used in, for
instance, CLI scripts or the various server components (xml-rpc, rest),
which have no concept of module or controller.
> > Hi Pat,
> >
> > Though a major use of Zend_Acl is to restrict access to action
> > controllers, Zend_Acl is not limited to this purpose. Thus, its API is
> > not specific to controllers, actions, and modules.
> >
> > Yes, Zend_Acl is extensible, so you should be able to define isAllowed()
> > in an extending class if you want to transform the API as you have
> > indicated.
> >
> > I think that the underlying issue is how you identify and structure your
> > resources. Zend_Acl is flexible on how resources may be identified, so
> > maybe something like the following would work for you:
> >
> > class My_Acl extends Zend_Acl
> > {
> > public function isAllowed($role, $module, $controller, $action)
> > {
> > return parent::isAllowed($role, "$module.$controller", $action);
> > }
> > }
> >
> > The dot separator is arbitrary, and Zend_Acl per se does not care about
> > what role and resource identifiers are used, only that they are unique.
> > So you can come up with your own resource naming schema however
> > appropriate for your needs.
> >
> > Judging from your deny() and allow() usage examples, however, I suspect
> > that you need to organize the resources such that modules are parents of
> > controllers.
> >
> > $acl->add(new Zend_Acl_Resource($module))
> > ->add(new Zend_Acl_Resource("$module.$controller"), $module);
> >
> > Alternatively, you could override these methods in an extending class if
> > you require a specific API (e.g., in your examples below).
> >
> > Hope that helps!
> >
> > Best regards,
> > Darby
> >
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
