ACL

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

ACL

Adrian Gheorghe
Hello everyone,

I've read a request a couple of days ago about testing Zend_Acl in
real applications and since I started working on a new project, here's
my experience.
The application would have 6 user types: organization administrator,
facility administrator, area manager, technician, security guard and
normal user. This can be easily mapped to the current Role structure,
and you could easily define permissions like: user has access only to
the home page and news, the security guard has access to the alarm
monitor, the technician to the engine's room, the area manager to the
area, the facility administrator to the facility and the organization
administrator to the entire organization's data.
The problem is this: the facility administrator should have access to
only a certain facility, inside which the area manager should have
access to only a certain area, the guard should only see alarms from
one facility and so on. Also, the facility adminstrator should be able
to assign permissions to users but only inside his facility.
Facilities, areas, everything would be edited live and the permissions
can be edited at any given time. Also, any person from the application
will have the group's permissions but the administrator should also be
able to modify it's permissions individually (for example the new
employees should not be able to enter a highly-secret-area, even if
they're part of a group which allows them to).
After some struggling I don't see how this is achievable with the
current structure and I don't believe this goes outside the 80/20
rule, so I hope there'll be some constructive ideas :)

Thanks,
Adrian Gheorghe.
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Darby Felton
What is preventing you from achieving this with the current structure? I
am definitely interested in understanding what we might be missing in
order to support a particular use case, but your message only describes
the problem you are trying to solve, without listing any specific
limitations that you encountered in trying to code it.

I believe that the use case that you described is in fact achievable,
though we may need to add some functionality to get there. What's missing?

Best regards,
Darby

Adrian Gheorghe wrote:

> Hello everyone,
>
> I've read a request a couple of days ago about testing Zend_Acl in
> real applications and since I started working on a new project, here's
> my experience.
> The application would have 6 user types: organization administrator,
> facility administrator, area manager, technician, security guard and
> normal user. This can be easily mapped to the current Role structure,
> and you could easily define permissions like: user has access only to
> the home page and news, the security guard has access to the alarm
> monitor, the technician to the engine's room, the area manager to the
> area, the facility administrator to the facility and the organization
> administrator to the entire organization's data.
> The problem is this: the facility administrator should have access to
> only a certain facility, inside which the area manager should have
> access to only a certain area, the guard should only see alarms from
> one facility and so on. Also, the facility adminstrator should be able
> to assign permissions to users but only inside his facility.
> Facilities, areas, everything would be edited live and the permissions
> can be edited at any given time. Also, any person from the application
> will have the group's permissions but the administrator should also be
> able to modify it's permissions individually (for example the new
> employees should not be able to enter a highly-secret-area, even if
> they're part of a group which allows them to).
> After some struggling I don't see how this is achievable with the
> current structure and I don't believe this goes outside the 80/20
> rule, so I hope there'll be some constructive ideas :)


Reply | Threaded
Open this post in threaded view
|

Re: ACL

Ralf Eggert
Hi Darby,

I am not quite sure, if I understood Adrian correctly. But I guess he
wants to do something like this:

$acl = new Zend_Acl();
$acl->addRole(new Zend_Acl_Role('facility_administrator'));
$acl->addRole(new Zend_Acl_Role('admin1'), 'facility_administrator');
$acl->addRole(new Zend_Acl_Role('admin2'), 'facility_administrator');

$acl->add(new Zend_Acl_Resource('facility'));
$acl->add(new Zend_Acl_Resource('facility1'), 'facility');
$acl->add(new Zend_Acl_Resource('facility2'), 'facility');

$acl->deny('facility_administrator', 'facility', 'whatever');
$acl->allow('admin1', 'facility1', 'whatever');
$acl->allow('admin2', 'facility2', 'whatever');

Now 'admin1' is allowed to do 'whatever' with 'facility1', but not with
'facility2'. And 'admin2' is allowed to do 'whatever' with 'facility2',
but not with 'facility1'.

And now think of a dozen of facility administrators for hundreds of
facilities. This would blow up the setup of the ACL dramatically. Or
think of a CMS with hundreds of users and thousands of articles. I think
it is almost impossible to setup every article as a ressource.

So how can I setup a scenario in which 'Darby' is only allowed to change
articles 4, 8 and 15 and 'Ralf' is only allowed to change articles 16,
23 and 42? Can I implement this scenario already with the current ACL?

Best Regards,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Darby Felton
Hi Ralf,

(sorry so long)

Ralf Eggert wrote:

> Hi Darby,
>
> I am not quite sure, if I understood Adrian correctly. But I guess he
> wants to do something like this:
>
> $acl = new Zend_Acl();
> $acl->addRole(new Zend_Acl_Role('facility_administrator'));
> $acl->addRole(new Zend_Acl_Role('admin1'), 'facility_administrator');
> $acl->addRole(new Zend_Acl_Role('admin2'), 'facility_administrator');
>
> $acl->add(new Zend_Acl_Resource('facility'));
> $acl->add(new Zend_Acl_Resource('facility1'), 'facility');
> $acl->add(new Zend_Acl_Resource('facility2'), 'facility');
>
> $acl->deny('facility_administrator', 'facility', 'whatever');
> $acl->allow('admin1', 'facility1', 'whatever');
> $acl->allow('admin2', 'facility2', 'whatever');
>
> Now 'admin1' is allowed to do 'whatever' with 'facility1', but not with
> 'facility2'. And 'admin2' is allowed to do 'whatever' with 'facility2',
> but not with 'facility1'.
>
> And now think of a dozen of facility administrators for hundreds of
> facilities. This would blow up the setup of the ACL dramatically. Or
> think of a CMS with hundreds of users and thousands of articles. I think
> it is almost impossible to setup every article as a ressource.

Of course, there is no way around the fact that the total ACL size will
be at least proportional to the number of Roles and Resources. Since the
ACL data structure contains little more than references to, and
identifiers for, these objects, the memory requirements are not too bad,
though I'm sure there is room for improvement. In many cases, developers
can reduce the storage requirements of the ACL by taking advantage of
inheritance (both among Roles and by the tree structure of Resources) as
it pertains to their particular use cases. Why is it impossible to setup
every article as a resource? If specific permissions are needed for a
particular article, there seems to be no way around having the article
represented in the ACL as a resource.

The points above do not include consideration for "partitioning" the
ACL. For example, if the ACL structure becomes too large to have in
memory in its totality, in many cases users might benefit from being
able to load only the subset of the ACL that is relevant to a particular
access control query. Because of Zend_Acl's inheritance support,
however, such partitioning might be rather complicated and/or might end
up offering little or nothing to the user with respect to performance.
Though we would gain the ability to reduce the amount of memory needed
by the ACL, the cost is extra execution time spent computing inheritance
 rules and lazy-loading only the needed portions of the ACL data
structure. I would like to see more supporting information before
deciding to make changes that would likely be regarded as premature
optimizations.

To me, this seems like a classic time vs. space problem, and I had tried
to design Zend_Acl such that:

1) Authorization queries are fast

2) ACL management operations may take longer than authorization queries

3) ACL objects are serializable

4) Memory footprint is low

I'm sure there are places where we could meet these goals better, and I
welcome any and all suggestions for doing so.

We could develop, for example, a database storage adapter that supports
the "partitioning" mentioned above, so that only the portions of the ACL
that are relevant to a particular query are lazy-loaded into the PHP
execution memory space. In many cases this would save some memory, but
the savings is only achieved at the cost of executing potentially
complicated SQL and taking more time to perform authorization queries as
the ACL is lazy-loaded.

> So how can I setup a scenario in which 'Darby' is only allowed to change
> articles 4, 8 and 15 and 'Ralf' is only allowed to change articles 16,
> 23 and 42? Can I implement this scenario already with the current ACL?

Yes, this scenario is currently supported. Each article to which access
is controlled could have an ACL Resource associated with it. Since
"privileges" are also supported upon Resources, you could also assign
allow/deny rules for specific article privileges as "view", "edit", and
"delete".

Best regards,
Darby
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Ralf Eggert
Hi Darby,

thanks for your feedback. Some points are much clearer now.

Since I am trying to separate my application into different modules it
would make sense to separate my ACL according to these modules. With
this separation I only need to load the ACL for the forum if the forum
is accessed. The same applies to the blog, the user management or other
site modules.

>> So how can I setup a scenario in which 'Darby' is only allowed to change
>> articles 4, 8 and 15 and 'Ralf' is only allowed to change articles 16,
>> 23 and 42? Can I implement this scenario already with the current ACL?
>
> Yes, this scenario is currently supported. Each article to which access
> is controlled could have an ACL Resource associated with it. Since
> "privileges" are also supported upon Resources, you could also assign
> allow/deny rules for specific article privileges as "view", "edit", and
> "delete".

Ok, I think I would set the mentioned scenario up like this. First the
basics:

  $acl = new Zend_Acl();
  $acl->addRole(new Zend_Acl_Role('guest'));
  $acl->addRole(new Zend_Acl_Role('editor'));
  $acl->addRole(new Zend_Acl_Role('Ralf'), 'editor');
  $acl->addRole(new Zend_Acl_Role('Darby'), 'editor');

  $acl->add(new Zend_Acl_Resource('article'));

  $acl->deny('guest', 'article', array('create', 'edit', 'delete'));
  $acl->allow('guest', 'article', array('view'));
  $acl->deny('editor', 'article', array('edit', 'delete'));
  $acl->allow('editor', 'article', array('view', 'create'));

Now both 'Ralf' and 'Darby' are allowed to 'view' and 'create' an
'article', but are not allowed to 'edit' or 'delete' an article. And
'guest' users can only 'view' an 'article'. This ACL object could be
cached somehow somewhere.

Every 'editor' is only allowed to 'edit' or 'delete' his 'articles'. So
the next step is to identify which articles the logged user is allowed
to 'edit' or 'delete'.

  // set $userId to 1 for user 'Ralf'
  $userId = 1;

  // now read the users articles and get the array(4, 8, 15)
  $articles = $articleModel->fetchArticlesForUser($userId);

  // populate the article ressources
  foreach($articles as $article)
  {
    $resource = new Zend_Acl_Resource('article_' . $article);

    $acl->add($resource);
    $acl->allow('Ralf', $resource, array('edit', 'delete'));

    // deny to use the 'create' rule for this article
    $acl->deny('Ralf', $resource, array('create'));
  }

The next step is to set up the resource for the current article. The id
of the article is saved in the $currentArticle variable.

  // set up the resource for the current article
  $myResource = new Zend_Acl_Resource('article_' . $currentArticle);

  // only add the resource if it has not been added before during
  // the foreach loop
  if (false === $acl->has($myResource ))
  {
    $acl->add($myResource );
  }

  // deny to use the 'create' rule for current article
  $acl->deny('editor', $resource, array('create'));

Finally I can start my queries for the ACL.

  echo $acl->isAllowed('Ralf', $myResource, 'view') ?
     "allowed" : "denied"; // allowed

  echo $acl->isAllowed('Ralf', $myResource, 'edit') ?
     "allowed" : "denied"; // allowed

  echo $acl->isAllowed('Ralf', $myResource, 'delete') ?
     "allowed" : "denied"; // allowed

  echo $acl->isAllowed('Ralf', $myResource, 'create') ?
     "allowed" : "denied"; // denied

  echo $acl->isAllowed('Darby', $myResource, 'view') ?
     "allowed" : "denied"; // allowed

  echo $acl->isAllowed('Darby', $myResource, 'edit') ?
     "allowed" : "denied"; // denied

  echo $acl->isAllowed('Darby', $myResource, 'delete') ?
     "allowed" : "denied"; // denied

  echo $acl->isAllowed('Darby', $myResource, 'create') ?
     "allowed" : "denied"; // denied

What do you think? Is this a good approach to solve this situation by
just populating the ACL with the resources for the current article and
the current user articles? Or do you see any drawbacks?

If this example is sophisticated enough maybe it could be added to the
documentation as well...

Thanks and Best Regards,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Andries Seutens

Why not implement a solution similar to Zend_Auth, where we use so
called "credentials" that should "pass" to obtain a valid resource?

eg:

$myResource = new Zend_Acl_Resource('article_edit');
$myResource->setValidCredentials('articles', array(1, 2, 3, 4));

This would save us a lot of code-lines...

Best regards,

Andries Seutens


Ralf Eggert schreef:

> Hi Darby,
>
> thanks for your feedback. Some points are much clearer now.
>
> Since I am trying to separate my application into different modules it
> would make sense to separate my ACL according to these modules. With
> this separation I only need to load the ACL for the forum if the forum
> is accessed. The same applies to the blog, the user management or other
> site modules.
>
>  
>>> So how can I setup a scenario in which 'Darby' is only allowed to change
>>> articles 4, 8 and 15 and 'Ralf' is only allowed to change articles 16,
>>> 23 and 42? Can I implement this scenario already with the current ACL?
>>>      
>> Yes, this scenario is currently supported. Each article to which access
>> is controlled could have an ACL Resource associated with it. Since
>> "privileges" are also supported upon Resources, you could also assign
>> allow/deny rules for specific article privileges as "view", "edit", and
>> "delete".
>>    
>
> Ok, I think I would set the mentioned scenario up like this. First the
> basics:
>
>   $acl = new Zend_Acl();
>   $acl->addRole(new Zend_Acl_Role('guest'));
>   $acl->addRole(new Zend_Acl_Role('editor'));
>   $acl->addRole(new Zend_Acl_Role('Ralf'), 'editor');
>   $acl->addRole(new Zend_Acl_Role('Darby'), 'editor');
>
>   $acl->add(new Zend_Acl_Resource('article'));
>
>   $acl->deny('guest', 'article', array('create', 'edit', 'delete'));
>   $acl->allow('guest', 'article', array('view'));
>   $acl->deny('editor', 'article', array('edit', 'delete'));
>   $acl->allow('editor', 'article', array('view', 'create'));
>
> Now both 'Ralf' and 'Darby' are allowed to 'view' and 'create' an
> 'article', but are not allowed to 'edit' or 'delete' an article. And
> 'guest' users can only 'view' an 'article'. This ACL object could be
> cached somehow somewhere.
>
> Every 'editor' is only allowed to 'edit' or 'delete' his 'articles'. So
> the next step is to identify which articles the logged user is allowed
> to 'edit' or 'delete'.
>
>   // set $userId to 1 for user 'Ralf'
>   $userId = 1;
>
>   // now read the users articles and get the array(4, 8, 15)
>   $articles = $articleModel->fetchArticlesForUser($userId);
>
>   // populate the article ressources
>   foreach($articles as $article)
>   {
>     $resource = new Zend_Acl_Resource('article_' . $article);
>
>     $acl->add($resource);
>     $acl->allow('Ralf', $resource, array('edit', 'delete'));
>
>     // deny to use the 'create' rule for this article
>     $acl->deny('Ralf', $resource, array('create'));
>   }
>
> The next step is to set up the resource for the current article. The id
> of the article is saved in the $currentArticle variable.
>
>   // set up the resource for the current article
>   $myResource = new Zend_Acl_Resource('article_' . $currentArticle);
>
>   // only add the resource if it has not been added before during
>   // the foreach loop
>   if (false === $acl->has($myResource ))
>   {
>     $acl->add($myResource );
>   }
>
>   // deny to use the 'create' rule for current article
>   $acl->deny('editor', $resource, array('create'));
>
> Finally I can start my queries for the ACL.
>
>   echo $acl->isAllowed('Ralf', $myResource, 'view') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Ralf', $myResource, 'edit') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Ralf', $myResource, 'delete') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Ralf', $myResource, 'create') ?
>      "allowed" : "denied"; // denied
>
>   echo $acl->isAllowed('Darby', $myResource, 'view') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Darby', $myResource, 'edit') ?
>      "allowed" : "denied"; // denied
>
>   echo $acl->isAllowed('Darby', $myResource, 'delete') ?
>      "allowed" : "denied"; // denied
>
>   echo $acl->isAllowed('Darby', $myResource, 'create') ?
>      "allowed" : "denied"; // denied
>
> What do you think? Is this a good approach to solve this situation by
> just populating the ACL with the resources for the current article and
> the current user articles? Or do you see any drawbacks?
>
> If this example is sophisticated enough maybe it could be added to the
> documentation as well...
>
> Thanks and Best Regards,
>
> Ralf
>
>
>
>  

--
Andries Seutens
http://andries.systray.be

i18n Locale Team is looking for your help.  Volunteers are always welcome to contribute their feedback, bug fixes, suggestions for enhancements and improvements, experimental patches, and especially their ideas on the fw-i18n mail list.

Are you enjoying the wiki manual?  They are frequently updated and incubator documentation is also included!

Live manual: http://framework.zend.com/wiki/display/ZFDOCDEV
Incubator manual: http://framework.zend.com/wiki/display/ZFDOC


Gecontroleerd op virussen door de JOJO Secure Gateway.
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Darby Felton
In reply to this post by Ralf Eggert
Hi Ralf,

Ralf Eggert wrote:
> Since I am trying to separate my application into different modules it
> would make sense to separate my ACL according to these modules. With
> this separation I only need to load the ACL for the forum if the forum
> is accessed. The same applies to the blog, the user management or other
> site modules.

In this case, you might be able to have a different ACL object for each
module, though you could also have a single ACL that has each module as
a first-level Resource:

ACL Resource Tree
|
+---- forum
|
+---- blog
|
+---- ...

> Ok, I think I would set the mentioned scenario up like this. First the
> basics:
>
>   $acl = new Zend_Acl();
>   $acl->addRole(new Zend_Acl_Role('guest'));
>   $acl->addRole(new Zend_Acl_Role('editor'));
>   $acl->addRole(new Zend_Acl_Role('Ralf'), 'editor');
>   $acl->addRole(new Zend_Acl_Role('Darby'), 'editor');
>
>   $acl->add(new Zend_Acl_Resource('article'));
>
>   $acl->deny('guest', 'article', array('create', 'edit', 'delete'));
>   $acl->allow('guest', 'article', array('view'));
>   $acl->deny('editor', 'article', array('edit', 'delete'));
>   $acl->allow('editor', 'article', array('view', 'create'));
>
> Now both 'Ralf' and 'Darby' are allowed to 'view' and 'create' an
> 'article', but are not allowed to 'edit' or 'delete' an article. And
> 'guest' users can only 'view' an 'article'. This ACL object could be
> cached somehow somewhere.

Since the default behavior of Zend_Acl is to deny, I think you may not
need the deny rules in the above code, unless you find value in having
them for clarity. The code should work as intended either way.

> Every 'editor' is only allowed to 'edit' or 'delete' his 'articles'. So
> the next step is to identify which articles the logged user is allowed
> to 'edit' or 'delete'.
>
>   // set $userId to 1 for user 'Ralf'
>   $userId = 1;
>
>   // now read the users articles and get the array(4, 8, 15)
>   $articles = $articleModel->fetchArticlesForUser($userId);
>
>   // populate the article ressources
>   foreach($articles as $article)
>   {
>     $resource = new Zend_Acl_Resource('article_' . $article);
>
>     $acl->add($resource);
>     $acl->allow('Ralf', $resource, array('edit', 'delete'));
>
>     // deny to use the 'create' rule for this article
>     $acl->deny('Ralf', $resource, array('create'));
>   }

Something you might consider if you haven't already is to let each
discrete article (e.g., 'article_1') inherit from an 'articles' resource:

ACL Resource Tree
|
+---- articles
      |
      +---- article_1
      |
      +---- article_2
      |
      +---- ...

You can assign "default" rules for articles on the 'articles' Resource,
and by inheritance, you need not specify these rules again on each
individual article. An example would be that 'guest' can 'view' all
articles, so I would have, as you have already indicated:

$acl->allow('guest', 'articles', array('view'));

If I need to know whether 'guest' can 'view' 'article_2', I can just
query against 'article_2', and inheritance takes care of the rest. Since
the parent Resource 'articles' already allows 'guest' to 'view', we need
not assign this rule upon 'article_2', since it is not specific to
'article_2'.

Only the rules specific to a particular article would need to be
assigned to the article itself (e.g., in the above code, allowing the
'edit' and 'delete' privileges for 'Ralf' would need to be assigned
directly to the article, as you have done).

> The next step is to set up the resource for the current article. The id
> of the article is saved in the $currentArticle variable.
>
>   // set up the resource for the current article
>   $myResource = new Zend_Acl_Resource('article_' . $currentArticle);
>
>   // only add the resource if it has not been added before during
>   // the foreach loop
>   if (false === $acl->has($myResource ))
>   {
>     $acl->add($myResource );
>   }
>
>   // deny to use the 'create' rule for current article
>   $acl->deny('editor', $resource, array('create'));

Looks okay to me, though I again notice that each Resource that is added
to the ACL tree does not inherit from another Resource, putting each
Resource only one level deep into tree.

> Finally I can start my queries for the ACL.
>
>   echo $acl->isAllowed('Ralf', $myResource, 'view') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Ralf', $myResource, 'edit') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Ralf', $myResource, 'delete') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Ralf', $myResource, 'create') ?
>      "allowed" : "denied"; // denied
>
>   echo $acl->isAllowed('Darby', $myResource, 'view') ?
>      "allowed" : "denied"; // allowed
>
>   echo $acl->isAllowed('Darby', $myResource, 'edit') ?
>      "allowed" : "denied"; // denied
>
>   echo $acl->isAllowed('Darby', $myResource, 'delete') ?
>      "allowed" : "denied"; // denied
>
>   echo $acl->isAllowed('Darby', $myResource, 'create') ?
>      "allowed" : "denied"; // denied
>
> What do you think? Is this a good approach to solve this situation by
> just populating the ACL with the resources for the current article and
> the current user articles? Or do you see any drawbacks?
>
> If this example is sophisticated enough maybe it could be added to the
> documentation as well...

Yes, I agree - we (not only you and me) have had some good discussions
on this list that I think we can take to improve the documentation.

Thanks for using Zend_Acl, and please let me know where you might see
areas that we can improve.

Best regards,
Darby
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Darby Felton
In reply to this post by Andries Seutens
Hi Andries,

Andries Seutens wrote:

>
> Why not implement a solution similar to Zend_Auth, where we use so
> called "credentials" that should "pass" to obtain a valid resource?
>
> eg:
>
> $myResource = new Zend_Acl_Resource('article_edit');
> $myResource->setValidCredentials('articles', array(1, 2, 3, 4));
>
> This would save us a lot of code-lines...

In a way, Zend_Acl might support this idea. Zend_Acl does support the
notion of "conditional rules," whereby a rule only applies if its
assertion returns true:

http://framework.zend.com/wiki/display/ZFDOCDEV/2.2.+Advanced+Use#2.2.AdvancedUse-WritingConditionalACLRuleswithAssertions

This idea may not be exactly what you had in mind, but I think that a
"conditional rule" is similar to what you show as a "credential," in
that both may be based on arbitrary business rules and both control
whether access is allowed or denied.

I might be misunderstanding your meaning, though.

Best regards,
Darby

Reply | Threaded
Open this post in threaded view
|

Re: ACL

Ralf Eggert
In reply to this post by Darby Felton
Hi Darby,

thanks for your feedback.

> In this case, you might be able to have a different ACL object for
> each module, though you could also have a single ACL that has each
> module as a first-level Resource:
>
> ACL Resource Tree
> |
> +---- forum
> |
> +---- blog
> |
> +---- ...

Yes, I was thinking about this as well. I need to check, how many
resources and rules I will need to get a better overview of the final
size of my ACL object. Maybe I don't even need to split it at all.

> Since the default behavior of Zend_Acl is to deny, I think you may not
> need the deny rules in the above code, unless you find value in having
> them for clarity. The code should work as intended either way.

Thanks for this note. I was not aware of this behavior but it will
simplify things as well. So I will only need to use the deny method for
roles that have inherited allowance.

> Something you might consider if you haven't already is to let each
> discrete article (e.g., 'article_1') inherit from an 'articles'
> resource:

Yes, I know that, I just forgot to add this to my quick and dirty
example. In my queries at the bottom of my mail I was taking the
inheritance already into account.

Thanks again for your great work on Zend_Acl!

Best Regards,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: ACL

Chintan Patel
This post has NOT been accepted by the mailing list yet.
Post Working Example of Zend_ACL with database..