In part one we saw how to setup our Zend_Acl instance and how to attach it to the MVC environment (by using the Front Controller Plugin), but what about setting another action for the denied access, or how does an article be edited only by its owner?, this, and some more is what we are going to see in the following examples.

This second part is broken up into a few parts:

• Using Modules
• Using Roles
• Setting the denied error action
• Using the action helper

These two tutorials are based on this proposal for the integration of Zend_Acl into the current framework is currently pending.

So, what is wrong with Zend_Acl and the current MVC implementation in the Zend Framework? there is nothing wrong, it is just that it gets not too obvious for developers how to achieve an optimal integration between these two important parts of the framework.

He talks about the proposal that's out for a potential update to the component, the two key points being the front controller plugin and a new action helper. He includes some sample code showing how to set it all up including a "denied" controller to handle the failures.

We previously covered how to authenticate an author to the blog, but we still have nothing ensuring only authenticated authors can access the new Administration Module. This is the domain of Zend_Acl, an implementation of an Access Control List system which limits access to resources by the roles assigned to a user.

He starts by helping you understand access control lists including roles and privileges. He plans out the different roles that he wants the application to have first (always a good first step) and then implements them in a class extending the Zend_Acl component. He wraps this all in a front controller to make it easy to use.

He also tosses in a bit there at the end about CSS and styling to handle the forms for login and the administration piece of the blog he created earlier.

I found that the base Zend_Acl package has some limitation/problem if you want to use it in a bigger real life project. Zend_Acl supports only logical roles, resources so I decided to extend it to allow using custom roles and resources which can represent existing entities (for example users/groups and topics in a database)

He talks some about the package and its current functionality, including the limitations he ran up against. He came up with a structure for what he wanted (seen here) and set out to extend the class, making an interface and implementing it with his own loading method.

His source code can be downloaded here.

Yesterday RC1 of Zend Framework was released. I have been working away using it for several months and I have tried to give back small snippets of code as I went along. I had to do some work on my class that extends the Zend ACL and it reminded me how I like to approach coding as a whole.

He goes on to look at what the Zend Framework access control functionality is and how he plans on using it. He follows this with a few code snippets that, among other things, show how the Zend_Config_Ini component could be used to maintain the access list.

After submitting the initial example of how Zend_Auth and Zend_Acl could be implemented Gavin pointed out areas that weren't really addressed in my proof of concept and it could potentially confuse newcomers to the way MVC is utilised. I'd like to clarify that post to a) Address those concerns and b) see if there's any constructive criticism of the process that could benefit everyone.

He sets up the site layout (including where the actions lie) and defines some of the access rules the script will follow. From there, he creates a bootstrap file and an index.php to work with it. On top of this, he builds the key piece - the Auth.php - to handle the validation of the users.