Adds a delegator to set a role for helpers

[froschdesign]

Q	A
New Feature	yes

Description

The delegator allows the setting of a role for navigation helpers by using a registered Laminas\Authentication\AuthenticationServiceInterface service and an existing identity.

Example of Usage

'navigation_helpers' => [
    'delegators' => [
        Laminas\View\Helper\Navigation::class => [
            Laminas\Navigation\View\RoleFromAuthenticationIdentityDelegator::class,
        ],
    ],
],

[froschdesign]

@Ocramius
I want to register this delegator so that it is present by default but this can then again be interpreted as a BC break.
What do you think?

[froschdesign]

The same applies to Laminas\Db\Adapter\AdapterAwareTrait and the registration for the database validators in laminas-validator.

[Ocramius]

IMO configuring this out of the box is a bit too much

[Ocramius]

What is going on here? O_o

[froschdesign]

This is for caching of the configuration.

[Ocramius]

Shouldn't the config only contain the delegator name?

[froschdesign]

I think this is not enough if serialization is used via var_export.

[weierophinney]

@Ocramius you can either specify a class name in the delegator configuration, or any callable. We've had a few cases where we've created delegator factory classes that optionally accept constructor arguments, which then allow them to vary their behavior; in such cases, providing a __set_state implementation allows them to work with caching.

[Xerkus]

var_export does not serialize/deserialize objects. Instead objects are exported as a call to ObjectClassName::__set_state() with object state passed as a map [property => value]. This method does not have default implementation and so it must be provided for the object in configuration to be "serializable" for the config cache

[Ocramius]

This is potentially broken, as it enforces temporal coupling between when the authentication storage has an identity (and role), and when the helper is built.

It's done in good faith, but IMO it is quite broken 🤔

[Ocramius]

Still, this is done in the view layer: potentially OK, but only works in traditional php-fpm based apps, not long-running apps.

[froschdesign]

This is potentially broken, as it enforces temporal coupling between when the authentication storage has an identity (and role), and when the helper is built.

Right, therefore the different checks before.

…but only works in traditional php-fpm based apps, not long-running apps.

Correct, but this applies to the view helpers in general.

[weierophinney]

Yeah, the whole laminas-view layer is crazy stateful, which is a problem for things like Swoole/ReactPHP/AMPHP. I steer people away from laminas-view for those applications, as we can't really address it any other way currently without a full rewrite — and if we want to do that, I'd argue we instead consider dropping it for something like mezzio-template, so that devs can choose their own poison templating solution.

I think this is fine for the current architecture.

[froschdesign]

IMO configuring this out of the box is a bit too much

The other idea is to create CLI command to register the delegator.

[weierophinney]

@froschdesign Seems sane enough, given the lamians-view architecture.

Only thing missing for me is documentation of how to attach the delegator, and why you'd want to.

[froschdesign]

@gsteel
Maybe it would be a better idea to use the plugin manager for the navigation view helper to inject the role and the ACL. What do you think?

https://github.com/laminas/laminas-view/blob/50ae82af3e2da96108490ceb474480e6df226993/src/Helper/Navigation/PluginManager.php#L23