Download the PHP package beatswitch/lock without Composer

Lock - Acl for PHP 5.4+

I'm sad to say that Lock is currently not maintained. I won't be able to offer support or accept new contributions for the current time being. Other priorities are keeping me from putting the work into Lock that it deserves. Eventually I'll try to pick up work again but unfortunately I cannot say when. My thanks goes out to all the contributors and users.

-- Dries

Lock is a flexible, driver based Acl package for PHP 5.4+.

Created by Dries Vints. Made possible thanks to BeatSwitch. Inspired by Authority by Matthew Machuga. Logo by Jerry Low.

Table of Contents

• Terminology
• Features
• Introduction
• Drivers
• Roadmap
• Installation
• Usage
  • Implementing the Caller contract
  • Working with a static driver
  • Working with a persistent driver
  • Setting and checking permissions
  • Clearing permissions
  • Setting an action alias
  • Setting a God caller
  • Working with roles
  • Working with conditions
  • Retrieving allowed or denied resources
  • Using the LockAware trait
• Api
• Building a driver
  • Testing your driver
• Maintainer
• Contributing
• Changelog
• License

Terminology

• Lock: An acl instance for a subject. This package currently ships with a CallerLock and a RoleLock
• Caller: An identity object that can have permissions to do something
• Driver: A storage system for permissions which can either be static or persistent
• Permission: A permission holds an action and an optional (unique) resource. Can be either a Restriction or a Privilege
• Restriction: A restriction denies you from being able to perform an action (on an optional resource)
• Privilege: A privilege allows you to perform an action (on an optional resource)
• Action: An action is something you are either allowed or denied to do
• Resource: A resource can be an object where you can perform one or more actions on. It can either target a certain type of resource or a specific resource by its unique identifier
• Role: A role can also hold multiple permissions. A caller can have multiple roles. Roles can inherit permissions from other roles

Features

• Flexible acl permissions for multiple identities (callers)
• Static or persistent drivers to store permissions
• Action aliases
• Roles
• Conditions (Asserts)
• Easily implement acl functionality on your caller or role with a trait

Introduction

Lock differs from other acl packages by trying to provide the most flexible way for working with multiple permission callers and storing permissions.

By working with Lock's Caller contract you can set permissions on multiple identities.

The Driver contract allows for an easy way to store permissions to a persistent or static storage system. A default static ArrayDriver ships with this package. Check out the list below for more drivers which have already been prepared for you. Or build your own by implementing the Driver contract.

You can set and check permissions for resources by manually passing along a resource's type and (optional) identifier or you can implement the Resource contract onto your objects so you can pass them along to lock more easily.

The Manager allows for an easy way to instantiate new Lock instances, set action aliases or register roles.

Drivers

If you need a framework-specific implementation, pick one of the already prepared drivers below.

• ArrayDriver (ships with this package)
• Laravel 5

Roadmap

• Group Permissions
• More drivers (Symfony, Zend Framework, Doctrine, ...)
• Event Listeners

Installation

Install this package through Composer.

Usage

Implementing the Caller contract

Every identity which should have permissions to do something must implement the BeatSwitch\Lock\Callers\Caller contract. The Caller contract identifies a caller by requiring it to return its type and its unique identifier. Let's look at an example below.

By adding the getCallerType function we can identify a group of callers through a unique type. If we would at some point wanted to set permissions on another group of callers we could easily implement the contract on another object.

And thus we can easily retrieve permissions for a specific caller type through a driver.

Working with a static driver

If you'd like to configure all of your permissions beforehand you can use the static ArrayDriver which ships with the package. This allows you to set a list of permissions for a caller before your application is run.

Working with a persistent driver

Working with a persistent driver allows you to store permissions to a persistent storage layer and adjust them during runtime. For example, if you'd implement the Laravel 5 driver, it would store the permissions to a database using Laravel's database component. By creating your own UI, you could easily attach the acl functionality from this package to create, for example, a user management system where different users have different permissions.

Let's take a look at a very basic user management controller to see how that's done. We'll assume we get a bootstrapped lock manager instance with our Laravel DB driver.

Every time the togglePermission method is used, the user's permission for the given action and resource type will be toggled.

Setting and checking permissions

You can either allow or deny a caller from doing something. Here are a couple of ways to set and check permissions.

Allow a caller to create everything.

Allow a caller to only create posts.

Allow a caller to only edit a specific post with an ID of 5.

Allow a caller to edit all posts but deny them from editing one with the id of 5.

Toggle a permission's value.

You can allow or deny multiple actions at once and also check multiple actions at once.

Clearing permissions

You can easily clear permissions for a set specific combination of actions and resources.

You can also just clear all permissions for a lock instance.

Setting an action alias

To group multiple actions and set them all at once you might want to set an action alias.

Setting a God caller

You could easily set a caller which has all permissions for everything by passing the all wildcard as an action on the lock instance.

Now every "can" method call will validate to true for this caller.

Working with roles

Lock provides an easy way to working with roles. You can work with roles out of the box but if you want to work with inheritance, you'll need to register the roles to the manager instance.

Or register multiple roles at once.

Let's set some permissions and see how they are resolved.

Something you need to be aware of is that caller-level permissions supersede role-level permissions. Let's see how that works.

Our caller will have the user role.

Working with conditions

Conditions are actually asserts which are extra checks you can set for permissions. You can pass an array with them as the last parameter of allow and deny. All conditions must implement the BeatSwitch\Lock\Permissions\Condition interface.

Warning: please note that conditions currently only work with static drivers.

Let's setup a condition.

Now let's see how this will work when setting up a permission.

You can also pass along multiple conditions.

You can pass along as many conditions as you like but they all need to succeed in order for the permission to work.

You can also use a callback if you like.

Retrieving allowed or denied resources

If you'd like to retrieve a list of resources which are allowed or denied to perform a particularly action you can use the allowed and denied methods on a Lock instance.

Please keep in mind that you can only retrieve id's from resources which have permissions set. Resources which aren't registered through Lock won't be returned.

Using the LockAware trait

You can easily add acl functionality to your caller or role by implementing the BeatSwitch\Lock\LockAware trait.

Now we need to set its lock instance.

And now your caller can use all of the lock methods onto itself.

If you have a caller which implements the LockAware trait but haven't bootstrapped the caller's lock instance yet you can easily make the caller lock aware by using the manager's makeCallerLockAware method.

And now your caller will be able to use the LockAware methods. There's a similar method for roles.

This will bootstrap a SimpleRole object which already comes with the LockAware trait in place.

Api

BeatSwitch\Lock\Lock

The following methods can all be called on a BeatSwitch\Lock\Lock instance.

can

Checks to see if the current caller has permission to do something.

cannot

Checks to see if it's forbidden for the current caller to do something.

allow

Sets a Privilege permission on a caller to allow it to do something. Removes any matching restrictions.

deny

Sets a Restriction permission on a caller to prevent it from doing something. Removes any matching privileges.

toggle

Toggles the value for the given permission.

allowed

Returns all the id's in an array of the given resource type to which the subject is allowed to perform the given action on.

denied

Returns all the id's in an array of the given resource type to which the subject is denied to perform the given action on.

BeatSwitch\Lock\Manager

The following methods can all be called on a BeatSwitch\Lock\Manager instance.

caller

Returns a BeatSwitch\Lock\Lock instance for a caller.

role

Returns a BeatSwitch\Lock\Lock instance for a role.

alias

Add an alias for one or more actions.

setRole

Set one or more roles and an optional role to inherit permissions from.

makeCallerLockAware

Sets the lock instance for a caller which implements the LockAware trait. Returns the caller with the lock instance set.

makeRoleLockAware

Sets the lock instance for a role which implements the LockAware trait. Returns the role with the lock instance set.

Building a driver

You can easily build a driver by implementing the BeatSwitch\Lock\Drivers\Driver contract. Below we'll demonstrate how to create our own persistent driver using Laravel's Eloquent ORM as our storage mechanism.

We'll assume we have a CallerPermission model class with at least the following database columns:

• caller_type (varchar, 100)
• caller_id (int, 11)
• type (varchar, 10)
• action (varchar, 100)
• resource_type (varchar, 100, nullable)
• resource_id (int, 11, nullable)

And we have a RolePermission model with the following database columns:

• role (varchar, 100)
• type (varchar, 10)
• action (varchar, 100)
• resource_type (varchar, 100, nullable)
• resource_id (int, 11, nullable)

Let's check out a full implementation of the driver below. Notice that for the getCallerPermissions method we're using the PermissionFactory class to easily map the data and create Permission objects from them. The PermissionFactory's createFromData method will accept both arrays and objects.

Notice that we're not checking if the permission already exists when we're attempting to store it. You don't need to worry about that because that's all been done for you in the Lock instance.

Now we have a driver which supports storing of permissions for callers and roles.

Testing your driver

It's very easy for you to make sure your driver works as expected. If you're building a persistent driver you can easily test it by creating a PHPUnit test which extends the PersistentDriverTestCase class.

And this is all you need! The PersistentDriverTestCase contains all the tests you'll need to make sure your driver works as expected. So if all those tests pass then your driver was set up correctly. No need to mock anything, this is a pure integration test case. Of course in this specific example above, for Eloquent to work you'll need to bootstrap Laravel. Working with a database like sqlite would be the best way here to test your driver.

Maintainer

Lock is unmaintained at this moment.

This package is currently maintained by Dries Vints.
If you have any questions please don't hesitate to ask them in an issue.

Contributing

Please see the contributing file for details.

Changelog

You can see a list of changes for each release in our changelog file.

License

The MIT License. Please see the license file for more information.