Right now I treat my models as resources with a special exception for the
user model which is both a resource and a role. Then I actually make the
models responsible for managing their own ACL permissions, both setting them
up and querying them. To facilitate that, I have a base model class that
does a few things. First it has a way to inject an ACL instance into the
model as well as a way to pass an ACL instance as the default ACL for all
models (which I do in my bootstrap). Second it automatically adds itself to
that ACL (with the resource id model:moduleName.modelName). Finally, I have
an *_initAcl()* method which is called when my model is instantiated which
adds the appropriate rules to the ACL if they don't already exist. Whenever
my model is doing something that is access-controlled I check the ACL right
then.
Here's a simple code example:
class Default_Model_Post extends Galahad_Model_Entity
{
protected function _initAcl($acl)
{
// Deny permissions to anything on this model unless explicitly
allowed
$acl->deny(null, $this);
// Allow guests to fetch the content of posts
$acl->allow('guest', $this, 'fetch');
// Allow admins to save changes to posts
$acl->allow('admin', $this, 'save');
}
public function save()
{
if (!$this->getAcl()->isAllowed($this->getRole(), $this, 'save')) {
throw new Galahad_Acl_Exception('Current user is not allowed to
save posts.');
}
$dataMapper = $this->getDataMapper();
return $dataMapper->save($this);
}
}
There's a little bit more happening in there (for example, I also have
helper methods like *getRole()*, which either gets the role ID stored in the
model or grabs it from Zend_Auth if available), but you should get the
picture.
That way my access control is happening when the access itself is happening.
No matter how my model is used, the ACL is always queried right when it
matters. I also like setting up the ACL this way because all rules are
loaded into the the ACL only when they could potentially apply (you never
need the rules for a Post model if the current request never even loads the
Post class).
This is something I've been thinking about a lot lately, and I'm just
settling into this method. I just blogged about it a little over a week
ago:
http://cmorrell.com/web-development/zf/namespacing-acl-resources-galahad-acl-737—
if anyone has any comments I'd love to hear them
CM
<http://cmorrell.com/> *Chris Morrell* Web: http://cmorrell.com Twitter:
@inxilpro <http://twitter.com/inxilpro>
On Fri, Mar 26, 2010 at 1:53 PM, jsuggs <jsu...@murmp.com> wrote:
>
> I'm trying to figure out what "layer(s)" should implement which aspect(s)
> of
> Zend_Acl. So I've got a few questions.
>
> Are the models the resources (ie. implements Zend_Acl_Resource_Interface)
> or
> does that belong solely in the service layer? I could see a case being
> made
> for the service class implementing/being the resource, but at the same time
> the service class could be (more or less) responsible for more than one
> resource/model (and service classes are not 1:1 with models, right?).
>
> What about the "User" model implementing Zend_Acl_Role_Interface?
>
> I understand that service layer is where you actually do the resource
> checks
> and allow/deny access, but just not 100% certain where/what the actual
> resources are. Any insight is greatly appreciated!
> --
> View this message in context:
> http://n4.nabble.com/Models-and-Services-ACL-Where-and-How-tp1692595p1692595.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
>
