2

I spent the day looking for tutorials and answers about how to implement Zend_Acl here at SO as in other sites. And I got a headache. :X

I saw people using it to allow or disallow access to certain controllers/actions and others saying that this way is incorrect, and that should allow or disallow access based on models. Huh, the second appears feasible, however, this means that for every controller I need a model? Because it seems, following the second alternative, I'll only be able to block user access at the moment it is, for example, editing a post. But I would like to prevent access to the action of the controller which edits the post.

If I want to block access to the user with role X to the action Y of the controller Z, how would I do that if I follow the second alternative?

An example of a real application would be very welcome.

This information can improve your answers: I use Doctrine 2 as ORM, and I have a module Admin. The actual structure of my application is like this:

application
  - MYAPP
    - configs
    - controllers
    - layouts
    - views
    - library
       - MYAPP ;This folder is in the include path
    - modules
       - admin
jonathancardoso
  • 11,737
  • 7
  • 53
  • 72
  • dude - you'll need to provide some more information. What is your ACL configuration for your specific case. i'd expect you to add some snippets of code so we can understand your question. – emeraldjava Jun 11 '11 at 21:16
  • @emeraldjava, I don't have a actual ACL configuration, like I said I'm confused about the various existing implementations. Here are some links that I've been reading, and as can be seen, they follow different paths: http://weierophinney.net/matthew/archives/201-Applying-ACLs-to-Models.html and http://stackoverflow.com/questions/2046608/practical-zend-acl-zend-auth-implementation-and-best-practices. – jonathancardoso Jun 11 '11 at 21:56

1 Answers1

5

I confess to being no Zend_Acl expert, but to me, the essence of using Zend_Acl is identifying the roles, the resources, and the privileges. The roles are usually pretty obvious. And once you have clearly identified the resources, the privileges often become apparent.

So to me, the key is identifying the resource.

In your circumstance, it sounds like you have explicitly identified the controller as the resource. If you need finer-grained access control, you could then define privileges to be the actions. This seems to be flexible enough so that even controllers that don't need to use models - perhaps static pages that should only be shown to logged-in users of a certain type, etc - can be ACL controlled.

There might be cases where you find that your resources/privileges "naturally" correspond to models/methods. But I don't think you should feel compelled to force your ACL into that paradigm if controllers/actions more closely matches your understanding of the program flow and ACL requirements.

Not really a direct answer to your question. More like advice to be true to your own read of the situation.

David Weinraub
  • 14,144
  • 4
  • 42
  • 64
  • completly agree, you could end with different ressources levels depending on modules (module allowed/forbidden), then for other modules you could prevent access based on controllers, then for other on actions, and for other on models, etc. Do not hesitate to build several independent Acl objects (and cache them) for each policy (and having 1 policy per module is usually usefull) – regilero Jun 12 '11 at 08:50
  • Thanks for the reply. @regilero Are you saying that if I have several types of resources, I'll need to define an acl for each (one based on controllers and the other based on models)? – jonathancardoso Jun 12 '11 at 13:14
  • @Jonathan: yes you CAN, it's not that you MUST but you should try to have several Acl objects if you want to apply several layers of ACL checks, so that you keep them small, understandable and unit-testable (and cacheable - sometimes big ACL objects with a lot of rules should even get splitted by roles). – regilero Jun 14 '11 at 14:45