Alex Tech Adventures The webs best tutorials!

Hi Alex,

Great tutorials. Found an interesting issue. When an action is being accessed that has an issue, it is going to throw an exception like the following:

Fatal error: Uncaught exception 'Zend_Acl_Exception' with message 'Resource id 'comment' already exists

I found that what was happening was that the setDynamicPermissions function was being called twice. In any event, if I placed a

if(!$this->has('comment')) around the addResource function, it took care of it.

Hope this helps

Yes, thats because when performing internal redirect, preDispatch is ran again therefore hitting setDynamicPermissions a second time. Need to address that when I do my error handling.

Hi Alex,

sorry to hijack this thread but wanted to ask if you could post the database structure etc for the tutorial.

I tried using the database structure and reproduce it watching your videos but I'm still getting errors.

Thanks,
Phil

I had to change the code & sql to work. What error are you getting?

Again thanks for the great video lessons!

Just a small question about the dynamic assertions: How would you solve the problem when you have an array of roles per user instead of just a single string?

Any suggestions?

Thanks!

As far as I know ACL does not accept arrays.
Maybe something like:


or am I thinking too simplistically?

I used this before I tried assertions. With the assertions in as well I couldn't get it to work. However I do think I might have implemented the assertions slightly incorrect as well. Next weekend I'll give it another try...

I don't really understand why multiple roles handling isn't build into ACL by default though. Many websites, even very small ones, often use multiple roles per user..

Actually I lied.
I don't know what made me think you can't pass an array as a parameter. In one of the code examples at framework.zend.com/manual/en/zend.acl.refining.html they do just that.
So you can have:
$permissions = array('read', 'write');
$this->allow('reporter', 'article', $permissions);

Adding permissions as an array works, but that doesn't solve the multiple roles per user problem. But I'll have another proper look into it next weekend. Maybe I went wrong somewhere with the resources or something..

Looking at your source code, I still don't really understand it..

Where do "Library_Model_UserRole" and "Library_Model_CommentResource" get instantiated? Am I missing something?

Second I still wonder where to fix the multiple roles problem, since you would need "Library_Model_UserRole" to allow an array instead of a string. You could ofcourse create a "Library_Model_UserRole" for every role, which is not very smart...

Maybe I am just missing the point, but I can't seem to figure it out.

Finally, I fixed it.

I did need some ticks and magic to get it done though. It isn't the most elegant solution but it does the trick. For others that might have the same problem a bit of explanation:

First of all, notice that the tutorial Alexander has made (which really is great and helped me out a lot) might not be exactly the same as what you might need in your website. In my case things are a bit different:
- my users have an array of roles instead of just one as a string
- my roles can't be hardcoded (except for my guest role which is an exception) since they come from the database
- some users are allowed certain priveleges depending on the resource, not just the role
- roles can conflict
- I used the assertions for the routing in my system, user (or guests) are allowed to go to a certain page depending on their role AND the assertion

Especially the last point is quite hard to solve in my case since a user has for example the priveleges to add a book, but not to edit or delete it. If you would look just at the roles you might never get to the page where the use can edit his own book details (which it is allowed to do->assertions)

Here is some relevant code I used:


/* accessCheck.php (plugin), as you can see I don't act on just the roles */

<?php
public function preDispatch(Zend_Controller_Request_Abstract $request){
$module = $request->getModuleName();
$controller = $request->getControllerName();
$resource = $module . ':' . $controller;
$action = $request->getActionName();

$allowed = FALSE;
$roles = Zend_Registry::get('userRoles');
foreach($roles as $id => $role_data){
if($this->_acl->isAllowed($role_data['role'], $resource, $action)){
$allowed = TRUE;
}
}

if(!$allowed){
Zend_Registry::set('Acl_Role_Allowed', FALSE);
}else{
Zend_Registry::set('Acl_Role_Allowed', TRUE);
}

$this->_acl->setDynamicPermissions();
}
?>


/* The assertion: */

<?php

public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface $role = null, Zend_Acl_Resource_Interface $resource = null, $privelege = null){
if(Zend_Registry::get('Acl_Role_Allowed')){
return TRUE;
}else{
if($role->getUserId() == $resource->getOwnerId()){
return TRUE;
}else{
return FALSE;
}
}
}
?>


/* Adding a book: No assertion need, just the roles need to be checked */

<?php
public function addAction()
{
if(!Zend_Registry::get('Acl_Role_Allowed')){
if(Zend_Auth::getInstance()->hasIdentity()){
$this->_redirect('/');
}else{
$this->_redirect('/authentication/login');
}
}
etc.
}
?>


/* editting a book, if either a role or the user is allowed, there is no redirect */

<?php
public function editAction()
{
$userRole = new Model_Acl_UserRole();
$albumResource = new Administration_Model_Acl_Resource_Album();

$album_id = $this->_getParam('id', 0);
if($album_id > 0){
$albums = new Administration_Model_DbTable_Albums();
$data = $albums->getAlbum($album_id);
}else{
throw new Exception('Error with album id');
}

$albumResource->setOwnerId($data['user_id']);

if(!Zend_Registry::get('Acl_Role_Allowed') && !Zend_Registry::get('acl')->isAllowed($userRole, $albumResource, 'edit')){
if(Zend_Auth::getInstance()->hasIdentity()){
$this->_redirect('/');
}else{
$this->_redirect('/authentication/login');
}
}
etc.
}
?>


I actually don't like doing this much work in the controllers, but haven't found an easy work around to fix this. What I might do next:
- make one folder contain all the assertions.
- if the assertion file for a certain module, controller, privelege combination exists: handle the rest like I do above in the controller and assertion
- if the file does not exist: let the preDispatcher handle it (since it only depends on the roles).

Hope this helps anybody, if there is anybody that can make it all a bit more elegant, let me know!

Hello Alex,
thank you very much for another great lesson, there is just one question, i was hoping you would answer.
As in the tutorial, there are on the top accordion pane, books listed with the ids 1,2,3 ...when your logged in as "john" your book are id 1 and 3, but not id = 2 ...so youll get the edit links ..../books/list/id/1 and /books/list/id/3 ...but what would happend when you type manually the url .../books/list/id/2 ...which doesnt belong to you ? can you still edit it? What to do against this ?

Thank you very much in advance.
-Ben

I'm quite sure that you would be able to edit them depending on your role (meaning that you still can't edit your own comment if you don't have the role permissions). I solved this problem, see my post before yours