add permissions capacity to RouteGuard and ControllerGuard #243
Conversation
jmleroux
changed the title
| return $this->protectionPolicy === self::POLICY_ALLOW; | ||
| } | ||
|
|
||
| if (in_array('*', (array)$allowedPermissions)) { |
There was a problem hiding this comment.
It is not clear to me, that 'roles' => 'foo' override (AND operation) 'permission' => 'bar' you would actually need a setting for that. Take this config for example:
'My\Controller' => [
'roles' => ['admin'],
'permission' => ['mayAccess']
]I think it is preferable to do something like this:
'My\Controller' => [
'roles' => ['admin'],
'permission' => ['mayAccess'],
'operator' => GuardInterface::OR_OPERATOR
]There was a problem hiding this comment.
Like discussed in #238, it will be another PR.
I keep it simple first.
|
@bakura10 and me hat a discussion some while back where we talked about this exact thing. He pointed out, that Guards should not be the single point of authorization but rather an additional security measure in your logic. Allowing programmers to add permissions could result in the neglect of implementing security measures in their respective services. However it seems as if #238 changed his mind. I think checking for permissions in controllers is a very convenient feature and I do approve of that. |
|
For me, not being able to check for permissions in route guards make it impossible to use ZfcRbac 2.x in lots of applications. I kept stuck with 0.2. |
|
@davidwindell |
|
@jmleroux how does this work if you have a ROLE and a PERMISSION, is it an or between these just as multiple roles/permissions would be an OR (for now)? |
|
For now, if there is a 'roles' key in configuration, then access is verified against roles. Permissions will not be tested. |
|
I think it would be better kept separate tbh as in #238, it would make configuration files cleaner when there are lots of routes. |
It's a choice. Others ? |
agreed! |
|
AAArrrggghhh :) So this PR is unnecessary. 😬 ? |
|
Closing this one, as it seems the separation between guards is the preferred one. |
Another way to manage permissions checks for RouteGuard as an alternative to #238
Discussion is open. ;)