First of all, I want to apologise. I just realised the title I used for
this post is not accurate and can lead to a misunderstanding. When I
said MVC integration of Zend_Acl, I was actually trying to match the
proposal's title I mentioned in my initial post. As the proposal was,
I'm in fact talking about applying Acls to the controller layer of the
MVC architecture (now as an analogy to Matthew's article: Applying Acls
to Models). My helper is intended to provide a solution for controllers
being considered as resources, and these only. Mea culpa.
As you said, a resource is whatever the developer want it to be. If in a
developer's mind controllers aren't resources, then there is no need to
use the helper, if just some are, then they can implement
Zend_Acl_Resource_Interface. If models (or files) are considered as
resources, they can be added and checked using their own way. It isn't
the helper's purpose and the developer keeps flexibility on that.
Secondly, when I'm talking about the plugin approach, which has the
choice to either allow all or deny all unknown resources, I'm talking
about the plugin that has been made from the same proposal. It is the
only one I've had the chance to have a look at and all my comments were
directed toward this one.
From what you said, yours seems to work fairly differently and to offer
a wider range of functionalities. I admit I'd be very curious to have a
look at it.
Finally, about loading the Acls from the database, once again it isn't
the responsibility of my helper. This stays the responsibility of the
developer's own solution. Your approach of loading acls from a nested
set table could be used to inject them within the helper, which doesn't
prevent other developers from using an xml file or hard coded rules and,
there again, the developer keeps total flexibility.
It doesn't look like our approaches are that much in opposition, mine is
just circumscribed to a specific set of resources, that is, the
controllers. Also, I do use has() and hasRole() too to prevent the
exception from being thrown.
I actually updated the page documenting the helper today, following the
comments I've had from you and others. Let me know your thoughts.
http://code.google.com/p/oolala/wiki/Oolala_Acl_Controller_Action_Helper_Acl
Thanks,
Thierry
Seth Atkins wrote:
> I see your logic, and it is hard to dispute that this approach would be
> good for a lot of applications. If I were in charge of a project such as
> integrating Zend_Acl into MVC (and I'm not), my chief criterion would be
> to assess not necessarily which is the best for a class of developers,
> but which is the most flexible for all (as far as I can tell, this
> criterion is used for most of ZF as the flexibility is one of the
> hallmarks of the architecture).
>
> Anyway, I'll simply make one suggestion and one counter to a point you
> made. The suggestion is simply that what makes your suggested approach
> good is also it's chief weakness. You point out that having controllers
> be resources and self defining as well is a great point. But on the
> other hand, it is limiting to others who really might not want to define
> a resource as a controller. What if the real "resource" you are trying
> to control is file access? Or what if the resource is data in a
> database. In such cases, the argument flips and a plugin is better
> simply because it DOES have the flexibility to define what is and is not
> a resource. A resource is whatever you want it to be. Just something to
> consider.
>
> The counterpoint is related to your comment that you might have to
> create a resource for every single controller in the application.
> Actually, this is not true. At least not if you implement dynamic ACLs.
> The concept may be a bit confusing if you haven't wrestled with it. It
> isn't exactly the most intuitive approach, but if you think through the
> system of loading rules dynamically, you can start to see that you don't
> have to load more rules than is necessary, and if the ACL loading
> doesn't find applicable rules to load, you can rest assured that the
> denial of access is warranted. You don't have to create blanket "allow"
> rules to work around this, because this is the intended behavior. Yes,
> you are correct that you have to not only have an isAllowed() call, but
> also a has() call, and in my case also a hasRole() call, just to
> circumvent the exception that may occur, and that is unfortunate, but
> necessary overhead.
>
> I personally like the flexibility that I can make anything I desire be a
> resource. In some cases, I have entire modules be a resource. This is
> because I simply want all controllers of that module to be accessible,
> and I don't want to have to specify permission to each controller. I
> only have to create the controller as a resource without any specific
> rules on that resource, as long as I have it inherit from the module.
> Similarly, I have modules inherit from a grouping of modules which I
> call resource types. Within my plugin, I query the module/controller
> from a nested set table listing my resource structure, and retrieve the
> simple inheritance tree branch. No more than 4 resources ever need to be
> created for any single request to my app, and that includes the site
> wide resource. Each of the 4 inherit from the one above. Then my rule
> loading method simply looks for rules that apply to any of those 4
> resources, and loads them. Yet at the same time, isAllowed() only checks
> the requested controller/action and has() only checks for the existence
> of the requested controller, yet it works because I've ensured the
> proper inheritance is built each time. It is actually very streamlined
> but also flexible.
>
>
> --Seth
>
> -----Original Message-----
> From: jThierry [mailto:thierry@jossermoz.net]
> Sent: Sunday, August 30, 2009 6:48 AM
> To: fw-mvc@lists.zend.com
> Subject: 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.ht
> ml
> Sent from the Zend MVC mailing list archive at Nabble.com.
>
>
>
>
>
没有评论:
发表评论