Note: this will be mostly an expansion on the solution that i provided in the linked article. I will not comment on answers from hakre.
As I understand your question, the issue basically is that you do not want to set access rights for each method separately.
Option 1: don't decorate
In the solution, that involves Decorator, one of the benefits is that, when you use the secured class (for example the Controller
, though it can be any part of application), you do not need to know that it has been decorated. Therefore, if you have some controllers that should be fully accessible to anyone, then you can just not decorate those.
This approach would most likely require the factory, that is responsible for instantiation of controller, to have some list of controller that should or should-not be wrapped in a decorator. Since this would always require an if
statement to consult the list, I personally would consider this only for instances on which you call more the one method (which, in my case, would exclude controllers).
Option 2: wildcards and whitelists
A different way tackle this would be take advantage of how you actually check for authorization.
$command = [ get_class($this->target), $method ];
This was the token, that get checked against. This means that the ACL receives not only the name of method, but also the full class name (including namespace, btw). It gives you an opportunity to create a list of rules that include both name of the class and method. Something along the lines of:
Controllers\Identification::* anonymous
Controllers\*::* admin
Controllers\Users::view authenticated
Controllers\Users::remove manager
Controllers\Users::add manager
The idea is that you save some configuration where you define all the allowed interactions. The ACL goes down the list, checking the user's group, and on first match returns the result (in the example the admins can access everything except login page, which is allowed only for unauthenticated users). Then again, this particular example would depend on you implementing at least partial groups-contain-groups functionality.
I would also reiterate, that you should only use white-lists for this. There is no significant risk added, if you forget to allow managers to remove users, but, if you forget to deny users to remove other users, it can be a critical mistake when using blacklist based authorization.
my two cents