I wonder when all the authentication and authorization packages are getting stable. It is quite hard to get the right mix of versions for these packages:
I cannot use the latest alpha versions of the first three packages because the forth package expects zendframework/zend-expressive-authentication to be ^0.4.
I use the authentication packages since months with no problems. With the authorization I cannot tell much because I just got my hands on them today.
Right now I am just struggling with the 401 and 403 responses that Zend\Expressive\Authorization\AuthorizationMiddleware generates because I get a blank page. Working with ZE 3.0.3 and the versions mentioned above. ErrorHandler is active in the pipeline and Whoops is also active. But still a blank page. Thought that the error.phtml should be displayed for these kind of errors.
Usually when you get a blank page and not the whoops page means there is another exception preventing whoops doing it’s work. If you log php errors, there should be an extra message in your php or nginx error log. Without that I’m afraid I can’t help with “a blank page” description.
Would it help to create a PR and allow 0.5 in zendframework/zend-expressive-authentication-acl? I’m not sure if that is enough or if it needs more code changes.
That is my actual problem. The error log is on and it works but not on the blank pages. I would love to present an error message to you. But I just can’t.
I just learned now that Zend\Expressive\Authorization\AuthorizationMiddleware returns almost naked Psr\Http\Message\ResponseInterface instances with a status code 401 or 403. These are not handled. If I add something like this
return new Response('php://memory', 500);
in my HomePageHandler I also get a blank page as well. I know that the return of a naked Response does not make much sense. But that seems the same situation to me. I lack a bit of knowledge which part of ZE has to handle these kind of returns that Zend\Expressive\Authorization\AuthorizationMiddleware delivers.
Ok, I will write my own AuthorizationMiddleware now which will return a redirect response to a custom unauthorized or forbidden page now. Cannot get the Zend\Expressive\Authorization\AuthorizationMiddleware to run properly in my setup.
Just to add my findings. I wrote my own AuthorizationMiddleware now which just throws a UnauthorizedException or a ForbiddenException with proper status codes. This is automatically handled by the ErrorHandler and passed to the error::error template. I use that template to show a 401 or 403 messages in these cases. So in the end, I don’t use these packages:
We’re planning on tagging 1.0.0 of zend-expressive-authentication early this week, and will gradually be tagging each of the adapters as we finalize them. (OAuth2 has quite a number of PRs currently, and some of them may also involve zend-expressive-authorization, which means it will likely be the last of the adapters to reach a stable tag.)
Authorization will follow shortly; there are a few changes we’ve identified due to OAuth2 usage.
Our plan is to finalize all of them in the next 3-4 weeks.
Is there any plans to extend zendframework/zend-expressive-authorization to more than “just” authorize routes : extend it to other ressources and privileges ?
and user is in charge of coming up with that string name and giving it meaning.
Authorization routes do not do a whole lot more than use route name as the resource name. Thus, any other component or resource, can be used just be assigning a name to it in the ACL/RBAC store.
Any more automation of name creation would step into realms of making opinionated application framework (think zfc-user), beyond a PHP “toolkit” that ZF is.
The zendframework/zend-expressive-authorization-acl only check isAllowed() on the $routeName (see ZendAcl.php#L48).
For instance, a resource could be a table inside a dashboard and check the privilege to delete a row.
I think it could be interesting to be able to check isAllowed() on a resource that is not a route and even more, be able to check privileges on that resource (just like it’s possible with zendframework/zend-permissions-acl).
That said, I get that zendframework/zend-expressive-authorization is designed to add a Middleware that authorize specific routes, so I’m “out of scope” here.
And of course, I can build my own Middleware that does what I need (check resources and privileges).
That said, I get that zendframework/zend-expressive-authorization is designed to add a Middleware that authorize specific routes, so I’m “out of scope” here.
And of course, I can build my own Middleware that does what I need (check resources and privileges).
