Bug Report

Summary

Previously it was possible to deny access to specific resource for all roles (with Zend_Acl)
$acl->deny(null, 'test1'); worked fine.
But now this behavior is changed. I would confirm that it is expected (or bug)

Current behavior

$acl->deny(null, 'test1');
$acl->isAllowed($roleGuest, 'test1') (result is true)

How to reproduce

Add following test and run:

    public function testRoleDefaultRuleSetResource(): void
    {
        $roleGuest = new GenericRole('guest');
        $this->acl->addResource('test1')
            ->addRole($roleGuest)
            ->allow($roleGuest);
        $this->assertTrue($this->acl->isAllowed($roleGuest, 'test1'));

        $this->acl->deny(null, 'test1');
        $this->assertFalse($this->acl->isAllowed($roleGuest, 'test1'));
    }

Expected behavior

I would expect to get false as result after $acl->deny(null, 'test1');

We are dealing with rules in the 70k - 100k 1k - 2k range. It currently takes setRule around 2.5 seconds to process all of these rules.

I have been able to increase the performance of this method by roughly 40% by simply eliminating the use of array_merge.

Suggested Change Acl line:580 to:

foreach($children as $child) {
    $resources[] = $child;
}

Suggestions on how this method can be improved further would be great appreciated. The tree that is being generated takes approximately 100-130ms to serialize/unserialize.

Note: Acl configuration will be cached in Production.

EDIT:
Sorry rules are in the 1500 - 2000 range. Roughly 300 roles and 300 resources.

Originally posted by @steverhoades at zendframework/zend-permissions-acl#4

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.dist in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require 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.

@ezimuel if you add this clarification I'll be appeased.

Originally posted by @TomHAnderson at zendframework/zend-permissions-acl#34

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

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7385
User: @BWorld
Created On: 2015-03-30T20:37:41Z
Updated At: 2015-11-06T21:03:17Z
Body
Hi,

I have the following setup:

$assertAllow = new TestAssertion(true);
$assertDeny = new TestAssertion(false);

$acl = new Acl();
$acl->addRole('staff');
$acl->addResource('base');
$acl->allow('staff', 'base', 'update', $assertAllow);

$acl->addResource('user', 'base');
$acl->allow('staff', 'user', 'update', $assertDeny);

var_dump($acl->isAllowed('staff', 'user', 'update'));
// Results into: bool true. expected false.

class TestAssertion implements AssertionInterface
{
        protected $value;
        public function __construct($value)
        {
                $this->value = $value;
        }

        public function assert(Acl $acl, RoleInterface $role = null, ResourceInterface $resource = null, $privilege = null)
        {
                return $this->value;
        }
}

http://pastebin.com/ZGsH8M1F

The expected outcome would be false but it returns true because in Acl::getRuleType() null is returned when the assertion is returning anything else than true.

A simple fix would be returning the assertion value if it is not null but I think I am missing some point here or this is something that is simply overlooked in the design.

If I did miss something please advice how to implement my assertions because I have assertions that are dedicated to a specific resourceId + roleId + privilege combination and I don't want to assign this whole combination to the assertion and let it check if this assertion is really meant for that call..

For example, staff can manage acl roles for users except for 2 users. This is not possible now since the inherited value which allows this behavior when it is actually denied.

Just to be clear, if an assertion exists and is returning otherwise than null stop searching and return that value instead of the parent resource's value.

Thanks

Originally posted by @GeeH at zendframework/zend-permissions-acl#20

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>whitesource/merge-confidence:beta)

Currently the implementation prohibits any implementation that is not Zends Acl.

Originally posted by @steverhoades at zendframework/zend-permissions-acl#5

Feature Request

Summary

PHP with version 8.1 is released and for this component the support of the new version is still missing.

…ot Acl.

Originally posted by @steverhoades at zendframework/zend-permissions-acl#6

BC Break Report

Summary

According to the documentation, an assertion determines whether a rule applies. It doesn't determine whether the rule is an allow rule or a deny rule.

From https://docs.laminas.dev/laminas-permissions-acl/advanced/:

...in all other cases (i.e., where a specific role, resource, or privilege is specified for the rule), a failed assertion results in the rule not applying, and other rules would be used to determine whether access is allowed or denied.

Previous behavior

If a specific 'allow' rule has an assertion that returns false, the rule is skipped, and any other more general rules are applied.

Current behavior

If a specific 'allow' rule has an assertion that returns false, it is being treated like a 'deny' rule.

How to reproduce

use Laminas\Permissions\Acl\Acl;
use Laminas\Permissions\Acl\Assertion\CallbackAssertion;

$acl = new Acl();
$acl->addRole('user');
$acl->addResource('asset');

$acl->allow('user', 'asset', 'read', new CallbackAssertion(
    fn ($acl, $role, $res, $priv) => false
));

$acl->allow('user', null, null);

var_dump($acl->isAllowed('user', 'asset', 'read'));

This code prints 'true' with version 2.7.1, but 'false' with version 2.7.2.

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