RE: [fw-mvc] MVC integration of Zend_Acl

Getting closer to the actual resource was why I decided to use a helper.
Because it has an access to the controller's instance itself whereas the
plugin has an access to the request object only.

What I found strange with the Plugin approach is that it seems the ACLs are
in charge of defining what is a resource. Let me explain. On each request, a
resource/privilege string is created from the request's properties (module,
controller, action). No matter what the controller where it is going to be
dispatched to is intended to be. Those string are then checked against the
ACLs via isAllowed(). The last throws an exception if the resource is
unknown or returns true or false if it is. In the second case, it's all
fine. But for unknown resources, the plugin has no way to tell whether the
string provided is supposed to be a resource or not. Then comes the choice
to deny them all, or to allow them all. If they're all denied, a resource
must then be created for every single controller in the application (e.g.
default/index), which is hard to maintain. If they're all allowed, if an
important resource is omitted (e.g. blog/article) there's a security issue
quite tricky to spot, but as the ACLs didn't define it as a resource, it
isn't one. The acls are then in charge of defining what a resource is.

With the helper approach, what I liked is that the resources define
themselves as such, providing an easy way to check what the controller is
intended to be. A single condition (is the controller not an instance of
Zend_Acl_Resource_Interface) allows to avoid checking anything, when an
exception would have been thrown in the plugin (or hasResource called) with
the problems I told above. Whenever the controller defines itself as a
resource by implementing the interface, the helper knows that if it is
unknown in the acls, odds are access should be denied. Furthermore, the acls
stay light weight without useless resources.

About adding code into the controllers, there isn't much more to do than
with the plugin approach. The helper knows what action has been called and
the preDispatch() method will check that automatically (as the helper has
been registered in the helper broker). The only code to add is the one
implementing Zend_Acl_Resource_Interface::getResourceId(). I added a
superclass for such controllers that already implement it using the helper
to normalise resource identifiers from the controller's class name.

Plugins' methods (routeStartup, routeShutdown, dispatchLoopStartup,
preDispatch) and Controller's init are a very good point and, I guess, why
I posted my question in the first place.

Seth Atkins wrote:
>
> Two main comments from my part. The first is a fairly open ended
> question I can't answer for you. While an action helper may fit your
> needs very well, IMHO, a successful integration is one which serves many
> common approaches and is the least limited implementation. For example,
> some of the comments so far have related to treating actions as
> resources. Many people see actions as privileges on resources, and one
> common view of what a resource is is a controller resource. If this is
> such a person's view on the subject, an action helper seems fairly
> limited since you are dispatching to a controller before you actually
> check resource access. I'd rather back things up a few steps and check
> before any particular resource is called. But that is my opinion, and I
> do know I'm not alone there. I believe, and correct me if I am wrong
> here, but the action helper preDispatch() method is called after the
> controller init(), which is also after any controller preDispatch()
> method, which is also after any plugin preDispatch methods. Seems to me
> a lot has happened before you ever checked to see if any of that should
> have happened in the first place.
>
> I am less familiar with all the things you can do with an action helper
> and how one might wrest it to do your will. My understanding of the ZF
> plugin architecture is more detailed since I have spent some time
> tracing through the code, how plugins are called, when, etc. Anyway, I
> know that plugins can do exactly what I want, but I'm less sure that an
> action helper would fit my needs.
>
> The second comment is that plugins are called before ANY dispatching (of
> any sort) occurs. Not even a controller init() method has been called
> yet. I can create one plugin, set it up in Zend_Application, and all my
> ACL code is in one place, once line of code to setup the plugin, and I'm
> done. The plugin is post routing, so it has the filtered request object
> to work from. You can load your rules and then feed isAllowed your
> controller or action name, or whatever criteria you want. If you want
> actions to be resources, fine. If you want controllers to be resources
> and actions privileges, fine.
>
> And best of all, a plugin can alter the request object before
> dispatching occurs. So I can actually redirect without "redirecting", if
> you know what I mean, in response to access being denied.
>
> To sum up, I don't think an action helper would be an implementation
> that I would personally want to use. I have many modules, many
> controllers, many actions, and while, yes, I could write one action
> helper and call it from anywhere, I'd really rather not have to write 50
> lines of code to just to call it from each controller I happen to have.
> And I'd rather not instantiate a controller that a person doesn't have
> access to in the first place. Just my 2 cents.
>
>
> --Seth
>
> -----Original Message-----
> From: jThierry [mailto:thierry@jossermoz.net]
> Sent: Thursday, August 27, 2009 9:44 PM
> To: fw-mvc@lists.zend.com
> Subject: [fw-mvc] MVC integration of Zend_Acl
>
>
> Hi all,
>
> I've been working on a component to realise the MVC integration of
> Zend_Acl which is different from the proposal
> (http://framework.zend.com/wiki/pages/viewpage.action?pageId=39025) that
> seems to be on hold.
>
> I'm using an action helper the perform the checks at pre dispatch time
> on controllers implementing Zend_Acl_Resource_Interface instead of a
> plugin and am wondering if there's any underlying reason that would
> encourage the use of a plugin.
>
> I would really much appreciate your feedback on the action helper
> approach.
>
> The code can be found there: http://code.google.com/p/oolala/
>
> Thanks,
>
> Thierry
> --
> View this message in context:
> http://www.nabble.com/MVC-integration-of-Zend_Acl-tp25183254p25183254.ht
> ml
> Sent from the Zend MVC mailing list archive at Nabble.com.
>
>
>
>

--
View this message in context: http://www.nabble.com/MVC-integration-of-Zend_Acl-tp25183254p25210847.html
Sent from the Zend MVC mailing list archive at Nabble.com.