Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend configuration to allow defining parents for resources #4

Open
eremem opened this issue Apr 16, 2020 · 3 comments
Open

Extend configuration to allow defining parents for resources #4

eremem opened this issue Apr 16, 2020 · 3 comments

Comments

@eremem
Copy link

eremem commented Apr 16, 2020

Feature Request

Q A
New Feature yes
RFC no
BC Break no

Summary

While porting an application based on Zend Framework 1 to Mezzio, I noticed that there seems to be no way to define a parent resource ID for the elements of ['mezzio-authorization-acl']['resources'].

It looks like a 'technical debt' in \Mezzio\Authorization\Acl\LaminasAclFactory::injectResources(), since \Laminas\Permissions\Acl\Acl::addResource($resource, $parent = null) allows passing a parent as its 2nd argument.

Comparing to the RBAC, it was IMHO a vital feature and an argument for using the ACL implementation in the first place. On the other hand, it makes the meaning of the 'deny' node in the configuration somewhat questionable - why denying access to any resource if you can just omit it in the 'allow' section?
Since there is effectively no way of configuring the grouping (or inheritance) of resources, we just get a plain list of allowed ones, which actually makes the whole ACL implementation logically similar (if not equal) to the RBAC... but with an overcomplicated configuration.

@weierophinney
Copy link
Contributor

I'm really unsure what you're asking.

Please expand your description to include some code or pseudo-code demonstrating:

  • syntax you want to use
  • what the results of that syntax will be

This will allow somebody to start working on a possible solution.

Thanks!

@eremem
Copy link
Author

eremem commented Apr 16, 2020

Sorry about the confusion.

Please consider the following resource hierarchy:

  • parent: user_administration
  • children: user & group

Configuration:

'mezzio-authorization-acl' => [
       'roles' => [
              'admin' => [],
       ],
       'resources' => [
              'user_administration',
              ['user', 'user_administration'], // <- inheritance not supported at the moment
              ['group', 'user_administration'], // <- inheritance not supported at the moment
       ],
       'allow' =>[
              'admin' => [
                     'user_administration',
              ],
       ],
]

The problem seems to be the current implementation of
\Mezzio\Authorization\Acl\LaminasAclFactory::injectResources(Acl $acl, array $resources):

foreach ($resources as $resource) {
       try {
              $acl->addResource($resource);
       } catch (AclExceptionInterface $e) {
              throw new Exception\InvalidConfigException($e->getMessage(), $e->getCode(), $e);
       }
}

The following could be a possible solution:

foreach ($resources as $resource) {
       try {
              $parent = null;
              if(is_array($resource)) {
                     if(count($resource) === 2) {
                            list($resource, $parent) = $resource;
                     }
                     else {
                            throw new Exception\InvalidConfigException('Invalid resource definition.');
                     }
              }
              $acl->addResource($resource, $parent);
       } catch (AclExceptionInterface $e) {
              throw new Exception\InvalidConfigException($e->getMessage(), $e->getCode(), $e);
       }
 }

@eremem
Copy link
Author

eremem commented Sep 21, 2020

Are my description and the proposed code samples clear enough?
What are the chances for integration of this "lost" feature in the near future?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants