Download the PHP package popphp/pop-acl without Composer

pop-acl

• Overview
• Install
• Quickstart
• Roles
• Resources
• Strict
• Multiple Roles
  • Multi-Strict
• Inheritance
• Assertions
• Policies

Overview

pop-acl is a full-featured component that supports ACL/RBAC user access concepts. Beyond allowing or denying basic user access, it provides support for roles, resources, permissions as well as assertions and policies for fine-grain access-control.

pop-acl is a component of the Pop PHP Framework.

Top

Install

Install pop-acl using Composer.

composer require popphp/pop-acl

Or, require it in your composer.json file

"require": {
    "popphp/pop-acl" : "^4.0.0"
}

Top

Quickstart

The basic concepts involve role and resource objects and then defining what permissions are allowed (or denied) between them. The main ACL object will determine if the requested action by a role on a resource is permitted or not.

The above also works with the string value names of the roles and resources:

Top

Roles

Besides being a store for a role name, a role object serves as a simple data object, should additional data need to be stored about the role or the user currently assigned to the role.

This is useful for deeper evaluations like policies.

Top

Resources

Like roles, the resource object serves as a simple data object to store additional data that may be needed.

This is useful for deeper evaluations like policies.

Top

Strict

Setting the strict flag strictly enforces any permissions that have been set and requires permissions to be explicitly set. If the strict flag is set to false, then ACL checks may pass as true if a rule is not explicitly set. Consider the following examples:

Both evaluations result in true, as there is no explicit rule preventing the editor from adding a page. In order to prevent the editor from adding a page, you would either have to set a deny rule:

Or, set the ACL to strict:

Top

Multiple Roles

If a user is assigned multiple roles at one time, those roles can all be evaluated at the same time. If we wire up a similar example from above:

we can then call the isAllowedMulti() method to evaluate multiple roles at once:

If one of the roles is permitted to perform the requested action on the resource, it will pass as true.

Multi-Strict

When evaluating multiple roles at once, if the requirement is such that all roles must be permitted to perform the requested action on the resource, using the multi-strict flag will ensure that.

Top

Inheritance

Roles can be constructed to inherit rules from other roles.

Top

Assertions

If you want more fine-grain control over permissions and who is allowed to do what, you can use assertions. First, define the assertion class, which implements the Pop\Acl\Assertion\AssertionInterface. In this example, we want to check that the user "owns" the resource via a matching user ID.

Then, within the application, you can use assertions like this:

Top

Policies

An alternate way to achieve even more specific fine-grain control is to use policies. Similar to assertions, you have to write the policy class and it needs to use the Pop\Acl\Policy\PolicyTrait. Unlike assertions that are centered around the single assert() method, policies allow you to write separate methods that will be called and evaluated via the can() method in the PolicyTrait. Consider the following example policy class:

It defines specific evaluations that are required for three different actions create(), update() and delete(). Then the user role and policy can be added to the main ACL object:

Once the polices are added to the ACL object, they will be automatically evaluated on the isAllowed() or isDenied() method calls:

A deeper look into what is happening under the hood, the ACL object is calling the method evaluatePolicy() to determine if the requested action is allowed:

Which, in turn, the `evaluatePolicy()` method calls are calling the `can()` method on the
actual policy objects themselves:

[Top](#pop-acl)