In your class UserCanModifyBlogPostAssertion, you are throwing an InvalidArgumentException if the role is not a User or the resource is not a BlogPost. I’ve found that this can cause a problem if you query the ACL with strings instead of objects:

$acl->isAllowed(‘user’, $blogPost, ‘modify’); // throws exception

Although the query doesn’t make a whole lot of sense, this is still correct usage of Zend_Acl. It may be better to return false in your assertion if you can’t work with the passed in objects.

That’s actually pretty funny, believe it or not. (-:

class Post implements Zend_Acl_Resource_Interface {
public $id;
public $authorId;
public function __construct($id = null, $authorId = null) {
$this->id = $id;
$this->authorId = $authorId;
}
public function isAuthor(User $user) {
return $user->id == $this->authorId;
}
public function getResourceId() {
if ($this->id) {
return “posts-{$this->id}”;
} else {
return “posts”;
}
}
}

class IsAuthorOfPost implements Zend_Acl_Assert_Interface {
public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface $role = null, Zend_Acl_Resource_Interface $resource = null, $privilege = null) {
// type checks
return $resource->isAuthor($role);
}
}

$acl = new Zend_Acl();
$acl->addRole(“users”)
->addRole(“authors”, array(“users”))
->addRole(“admins”)
->addResource(“posts”)
->allow(“admins”, “posts”)
->allow(“authors”, “posts”, “create”)
->allow(“authors”, “posts”, array(“delete”, “edit”), new IsAuthorOfPost());

$allan = new User(1, “users”);
$acl->addRole($allan, $allan->role);

$mary = new User(2, “authors”);
$acl->addRole($mary, $mary->role);

$joe = new User(3, “authors”);
$acl->addRole($joe, $joe->role);

$mike = new User(4, “admins”);
$acl->addRole($mike, $mike->role);

var_dump($acl->isAllowed($allan, new Post(), “create”)); // false, users cannot create posts
var_dump($acl->isAllowed($mary, new Post(), “create”)); // true, authors can create posts
var_dump($acl->isAllowed($joe, new Post(), “create”)); // true, authors can create posts
var_dump($acl->isAllowed($mike, new Post(), “create”)); // true, admins can do anything with a post

$joesPost = new Post(1, $joe->id);
$acl->addResource($joesPost, “posts”);

var_dump($acl->isAllowed($allan, $joesPost, “edit”)); // false, Allan is not an author
var_dump($acl->isAllowed($mary, $joesPost, “edit”)); // false, Marry is not the author of the post
var_dump($acl->isAllowed($joe, $joesPost, “edit”)); // true, Joe is the author of the post
var_dump($acl->isAllowed($mike, $joesPost, “edit”)); // true, admins can do anything with posts

// if role is publisher, he can always modify a post
if ($user->getRoleId() == ‘publisher’) {
return true;
}

Shouldn’t this instead be handled at the ACL level:
$acl->allow(‘publisher’, ‘blogPost’, ‘modify’);

Is it because publisher inherits from contributor? Would my example work if this permission was removed from UserCanModifyBlogPostAssertion?


$roles = $identity['ROLES']; //array of string roles are associated with the user perhaps from db
$acl->addRole(new Zend_Acl_Role('user-'.$name),$roles); //make sure ACL knows about this new "role"
$user->setRoleId('user-'.$name);


Just wondering – how would you go about spitting out a list of blog posts that a user is able to edit?

Some might suggest that models are module-specific but I dare to question that. It is quite normal that different modules from you application use the same model. Modules are not a means to separate the model, but they contribute behaviour to an application. I can agree what you say
“A Module is a collection of code that solves a more specific atomic problem of the larger business problem.” But I miss the notion of «general/reusable/application agnostic behaviour».

Maybe we could define it as “A Module is a pluggable and reusable stand-alone collection of code that solves a (more or less) concrete larger business problem.”

Maybe I went off-topic. Maybe I am nit-picking.