Embracing middlewares

[bakura10]

Hi everyone,

In overall, this package has been very stable over the last few months, and I'd like to think about the future of it.

With the increase of API, and tools like Zend\Expressive, it may be interesting to simplify this package. I'd like to support two different branches: 2.x that would be based as a ZF2 module, and a 3.x branch, that would remove dependency completely toward ZF, and embrace middlewares and an API first design.

Here are the various things I'm thinking, let me know if you have any suggestion.

Removing guards

Guards were nice, but to be honest, they were a bit problematic. They were tied very strongly to the ZF2 router / ZF2 MVC model, and while useful to "guard" a bunch of route (/admin/*), the advent of middlewares allow to create much better solution to this issue.

Also, guards introduced potential security issue, as some methods could be called outside the context of a route/controller, hence bypassing the guard.

This also made testing harder, because, well... testing taht kind of things is hard because it's 100% config.

Instead, we should encourage people to check their permissions at the controller/service level. I've always done it at the controller level, and it was super nice. Very easy to see which permissions were needed, very easy to test...

** Removed dependencies **: zend\mvc

Removing views

As a package that would be API driven does not need the views anymore.

** Removed dependencies ** : zend\view

Removing collector and various ZfTool

No longer really needed, and we don't have yet a tool for that in middleware's world.

Authentication

ZfcRbac would no longer rely on Zend\Authentication. Instead, the isGranted signature would be changed so that the first parameter is an IdentityInterface:

interface AuthorizationServiceInterface
{
    public function isGranted(IdentityInterface $identity, $permission, $context = null);
}

Consumer would be responsible to extract it. In PSR-7, each request can be set attribute, for instance here is a possible controller:

public function fooAction(ServerRequestInterface $request)
{
   $identity = $request->getAttribute('logged_user');

   if ($this->authService->isGranted($identity, 'my_perm', ['context' => 'bar']) {

   }
}

Maybe we could provide some simple, common interfaces for retrieving logged identity, I'm not so sure.

ping @danizord @weierophinney

[danizord]

@bakura10 awesome! I was a bit unsure about the future of Rbac component and ZfcRbac in this middleware age, but your ideas motivated me again :D

Absolutely 👍, finally we can have AuthorizationService stateless.

We could provide some middleware abstraction to replace 2.x guards:

// You need "access_admin" permission to access /admin/* routes
$app->pipe('/admin', new PermissionGuardMiddleware('access_admin'));

Tell me how I can help (I know, I owe you some migration docs, heh. Will finish it by the end of the week ;-))

[bakura10]

That's a nice idea Daniel!

Well how you can help me? First you need to finish your rbac PR so we can have it as a Zend component. And then you can start implementing those ideas. I'm still overwhelmed with front end work for months so I don't have much time for working on PHP stuff unfortunately ;(

Envoyé de mon iPhone

Le 1 oct. 2015 à 20:56, Daniel Gimenes notifications@github.com a écrit :

@bakura10 awesome! I was a bit unsure about the future of Rbac component and ZfcRbac in this middleware age, but your ideas motivated me again :D

Absolutely , finally we can have AuthorizationService stateless.

We could provide some middleware abstraction to replace 2.x guards:

// You need "access_admin" permission to access /admin/* routes
$app->pipe('/admin', new PermissionGuardMiddleware('access_admin'));
Tell me how I can help (I know, I owe you some migration docs, heh. Will finish it by the end of the week ;-))

—
Reply to this email directly or view it on GitHub.

[bakura10]

Any news @danizord about the work you could do for Rbac ? :)

[aeneasr]

👍 I actually left php for Go. Middleware was one of the many reasons ;D

[bakura10]

Oh ok… sad to see you leave, so I’d just want to thank you for all the work you’ve done on ZfcRbac, if the library is as good and stable as it was it was also because of you :).

Le 5 nov. 2015 à 09:25, Aeneas notifications@github.com a écrit :

I actually left php for Go http://golang.org/. Middleware was one of the many reasons ;D

—
Reply to this email directly or view it on GitHub #307 (comment).

[aeneasr]

Thanks man, appreciated! Keep on rocking! 👍
I'm always available if you want feedback on stuff. :)

[danizord]

@bakura10 Working on that right now. Will push some stuff tomorrow or next weekend ;)

[bakura10]

@danizord , could I have your help to update all the tests? We've been quite tricked by ZfcRbac test suite that relied heavily on the module and service manager, which now is a big hassle :(.

I'd like to make the test suite pass first before doing more refactoring and fixing design issues.

Here are the things that need to be fixed in tests:

• Factory
• Identity
• Role
• Service
• Util (likely to be removed)

[danizord]

@bakura10 sure, but I have to leave now and I will be back later tonight, ok?

[bakura10]

Sure!

[basz]

Hi @bakura10 can I offer some assistance here?

Anything simple to get me started. I'm anxious to get into middleware style applications and this seems like a good starting point.

[bakura10]

Sure. The first thing right now is to start fixing tests (you could make some PR to this branch: #312)

Also, it would be nice to think about the general architecture. As outlined in the other discussion:

I'm not sure to understand how the flow would work actually. The current identity is provided by the "RoleService", which itself has a dependency to an IdentityProviderInterface (which used to use Zend\Authentication).

Because we are using a middleware approach, I'd think that the good approach would be to have a middleware that would do the authentication logic and store the logged user (if any) as part of the request attributes. However how the RoleService would retrieve the request to get the identity?

The workflow is a bit confusing for me :(.

[basz]

ke, made a start with some of the factories tests.
Q: Do you want tests to reference service name by FQCN::class?