Config for version 3.0 needs some fixing or explaining about zfc-rbac

[basz]

I'm using the ConfigAggregator in an expressive application, works out of the box.

$configManager = new ConfigAggregator([
    ...,
    \ZfcRbac\ModuleConfig::class,
    new PhpFileProvider($globPattern),
], \sprintf('data/cache/config-%s.php', APP_ENV));

return $configManager->getMergedConfig();

// config/autoload/zfc-rbac.global.php

return [
    'dependencies' => [
        'factories' => [
            \ZfcRbac\Role\RoleProviderInterface::class => \ZfcRbac\Container\InMemoryRoleProviderFactory::class,
        ],
    ],
    'zfc_rbac' => [
        'role_provider' => [
            InMemoryRoleProvider::class => [

            ], 
        ],
        'assertion_map' => [
        ],
    ],
];

For zf3 you should only have to change dependencies to service_manager I guess.

[svycka]

I am just thinking what people will do with something other than Zend\ServiceManager how hard would be with Symfony or Laravel?

and 'dependencies' => [... thing is zend-expressive specific so maybe we should load this config after install as other repressive modules do through expressive installer like this: https://github.com/svycka/swagger-middleware/blob/master/composer.json#L60-L63

[basz]

I am just thinking what people will do with something other than Zend\ServiceManager how hard would be with Symfony or Laravel?

About decoupling from zf service manager: problem might be that we use the plugin manager for assertion plugins. Then again a plugin manager is just a nested container in theory.

I don't know how symfony or laravel does this and how it would impact "modules" such as this one... If you think we can support them easily I see no reason why not to do it.

and 'dependencies' => [... thing is zend-expressive specific so maybe we should load this config after install as other repressive modules do through expressive installer like this: https://github.com/svycka/swagger-middleware/blob/master/composer.json#L60-L63

yes, i agree we should do that

[svycka]

About decoupling from zf service manager: problem might be that we use the plugin manager for assertion plugins. Then again a plugin manager is just a nested container in theory.

It's already done we only use ZF service manager internally for assertions, but config files are structured for ZF service manager but that's the only thing what stops from using something else. We can change the configuration to whatever we need. All factories use PSR-11 and could be used with any PSR-11 implementation as I understand.
But I do not have much experience with Laravel or Symfony maybe there is problems I don't know :)

[prolic]

As far as I know there are no plugin managers (like in ZF) available in symfony or laravel.

[svycka]

@prolic we don't need a plugin manager any PSR-11 implementation is good to go as we only use $container->get('something'). Okay, maybe only config or custom setup required for PSR-11 container and not sure but maybe one or two factories will have to be changed but that's it. Maybe would be better to create few separate projects making as modules for laravel or symfony

[imonteiro]

Not that bad but still maybe someone can suggest something better? Maybe we should support ZF and expressive by default since we have everything ready for them? And also not existing documentation.

I would like to test the 3.0.0-alpha.1 release with my expressive application. Beside the config aggregator, which additional steps I need to call the ZfcRbac Authorization from pipeline or route?

Thanks in advance.

[svycka]

@imonteiro that's for you to decide. you only need to have an identity. Basically, this lib has only one method $authorization->isGranted($identity, 'permission') it no longer has guards as in 2.x version like RouteGuard, of course, you can easily implement yourself.

[imonteiro]

@svycka I get it. Thanks 👍