ACL usage and a Singleton implementation for a facilitated granularity of the access control

[lotharthesavior]

Hello,

I was thinking about the usage of the ACL in the applications, and the granularity of it. I'm thinking this because we might give a deeper level of verification, other than controlling access to routes.

If we go to the zend-permissions-acl, which happens to be used by us (https://framework.zend.com/blog/2017-05-09-zend-permissions-acl.html), we will find that it is expected the used spread through the application, and we would be able to check the role and the permission at many other levels.

But once we focus here only in the routes, we don't have a way of doing that because for that we will have to keep an instance in the app container.

Wouldn't it be facilitated by a Singleton implementation? It could be achieved by turning the constructor protected (not private because it will be extended) and by adding this method to the AclRepository:

public static function Instance()
{
    static $inst = null;
    if ($inst === null) {
        $inst = new MyAcl();
    }
    return $inst;
}

Am I misunderstanding the goal of this tool, or it makes sense?

[CodelineRed]

I made something like this:

• AclUtility
• middleware
• PageController

May be it is what you are looking for.

[lotharthesavior]

Hey, thanks @InsanityMeetsHH .

I just want to ask that, when you use the class AclUtility, if you enforce the single instance somehow. I understand that this is suggested once we have the "getInstance", but I have concerns about the encapsulation when this is the case.