Running two guards in parallel with protection policy deny

[DennisDobslaf]

Hi, I have an issue, that is implemented by design. I'm not sure, if it's known or intended.

If you want to run two guards at the same time, e.g. for protecting an admin area by IP (with the IP Guard of the docs right here), but also running a RoutePermissionsGuard, you will not be able to access any ressource, unless ALL of the configured guards will say "YES" it's okay.

I build a simple example for that:

I want to protect a page (here 'impressum'; let's assume it's a secure imprint page).

'zfc_rbac' => [
    'guard_manager' => [
        'invokables' => [
            'Application\Guard\DummyGuardReturnsTrue' => 'Application\Guard\DummyGuardReturnsTrue'
        ]
    ]
],

'zfc_rbac' => [
    'guards' => [
        'ZfcRbac\Guard\RoutePermissionsGuard' => [
            'home' => ['*'],
            'archiv' => ['*'],
            //'impressum' => ['*'],
            'application-nopermission-fails' => ['*'],
        ],
        'Application\Guard\DummyGuardReturnsTrue' => [
            'impressum' => ['*']
        ]
    ]
],

The first guard previously knew the page and gave access. For purpose I commented these lines out. The second guard now is responsible to grant access for 'impressum'. As the guard name says, it always returns true. Altough my implementend guard would grant access, the user will be blocked from this page. That's because of the implementation in

ZfcRbac\Guard\AbstractGuard::onResult(MvcEvent $event)

If one guard declines access, there is no way to get to the page, route, or whatever.

Is that the right way? I would assume that if one guard says YES, than you can access the page.
Or is there any other way implementing the behaviour I need?

Thanks so far

Dennis

[DennisDobslaf]

In addition to my previous comment, I have to say, that if one guard does not know anything about a route, controller or whatever, but another one does, it must not be responsible for blocking access to the ressource.

[claytondaley]

I ran into this exact same issue. It makes the switch from ALLOW to DENY extremely complicated since you basically have to start from scratch -- technically add tons of explicit ALLOWs all over the place (sometimes to routes and controllers whose name you don't actually know). After the fact, I realized the documentation actually does state this:

In this mode, once a guard is added, anything that is not explicitely added will be refused by default.

The suggestion in Issue #263 would vastly simplify the process. That way you could have one Deny-by-Default guard... and tweak the behavior for a few specific cases using other ALLOW guards. At minimum, you could switch guards over one at a time so you'd know what was causing the DENY.

In my case, I suspect that I'll be better off consolidating all the behavior in one ControllerPermissionsGuard, but I definitely felt your pain. I was actually writing up a proposal to improve the DENY documentation when I stumbled upon your equivalent issue.