Feature Request

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0

Feature Request

Summary

As of now the laminas-permissions-acl gets created within the LaminasAcl factory (https://github.com/mezzio/mezzio-authorization-acl/blob/master/src/LaminasAclFactory.php#L46).

Besides the usage within the authorization-middleware (https://github.com/mezzio/mezzio-authorization/blob/master/src/AuthorizationMiddleware.php) via the isGranted() method I would like to be able to use it, in my case, inside a view helper to show/hide navigation items according to the route and currently logged-in user.
Problem is, I cannot access the isAllowed() of the Acl from outside the LaminasAcl. Neither can I extend the LaminasAcl to use the acl property as it is private.
I would need to hydrate the Acl another time by myself to be able to use it.

Some solutions I have in mind (either/or):

• add an isAllowed() proxy method to the LaminasAcl
• add a getAcl() to the LaminasAcl
• move the new Acl() + resource/roles/rule hydration into its' own service/factory to request it via $container->get(Acl::class)

I'm happy to prepare a pull-request according to whatever the outcome is.

What do you think?

Feature Request

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a psalm.xml in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require --dev vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency phpunit/phpunit to v11

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Feature Request

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.