Authorization Component gives you the ability to create custom ACL metrics which is unique to each of your extension/application. The component works best with Auth Component but you could as well implements Orchestra\Contracts\Auth\Guard.

In most other solutions, you are either restrict to file based configuration for ACL or only allow to define a single metric for your entire application. This simplicity would later become an issue depends on how many extensions do you have within your application.

1. Version Compatibility
2. Installation
3. Configuration
4. Usage
   • Concept of RBAC
   • Creating a New ACL Instance
   • Verifying the ACL
   • Integration with Memory Component
5. Change Log

Version Compatibility

Laravel	Authorization
5.0.x	3.0.x
5.1.x	3.1.x
5.2.x	[email protected]

Installation

To install through composer, simply put the following in your composer.json file:

{
    "require": {
        "orchestra/authorization": "~3.0"
    }
}

And then run composer install from the terminal.

Quick Installation

Above installation can also be simplify by using the following command:

composer require "orchestra/authorization=~3.0"

Configuration

Next add the service provider in config/app.php.

'providers' => [

    // ...
    Orchestra\Authorization\AuthorizationServiceProvider::class,
    Orchestra\Memory\MemoryServiceProvider::class,

    Orchestra\Memory\CommandServiceProvider::class,
],

Aliases

To make development easier, you could add Orchestra\Support\Facades\ACL alias for easier reference:

'aliases' => [

    'ACL' => Orchestra\Support\Facades\ACL::class,

],

Usage

1. Concept of RBAC
2. Creating a New ACL Instance
3. Verifying the ACL
4. Integration with Memory Component

Concept of RBAC

Name	Description
actions	Actions is either route or activity that we as a user can do (or not do).
roles	Roles are user group that a user can belong to.
acl	Is a boolean mapping between actions and roles, which determine whether a role is allow to do an action.

Creating a New ACL Instance

<?php

$acl = ACL::make('acme');

Imagine we have a acme extension, above configuration is all you need in your extension/application service provider.

Verifying the ACL

To verify the created ACL, you can use the following code.

$acl = ACL::make('acme');

if (! $acl->can('manage acme')) {
    return redirect()->to(handles('orchestra::login'));
}

Or you can create a route middleware.

<?php namespace Acme\Http\Middleware;

use Closure;
use Orchestra\Support\Facades\ACL;

class ManageAcme
{
    public function handle($request, Closure $next)
    {
        if (! ACL::make('acme')->can('manage acme')) {
            return redirect()->to(handles('orchestra::login'));
        }

        return $next($request);
    }
}

Integration with Memory Component

Integration with Memory Component would allow a persistent storage of ACL metric, this would eliminate the need to define ACL on every request.

Creating a New ACL Instance

<?php

ACL::make('acme')->attach(Memory::make());

Migration Example

Since an ACL metric is defined for each extension, it is best to define ACL actions using a migration file.

<?php

use Orchestra\Model\Role;
use Illuminate\Database\Migrations\Migration;

class FooDefineAcl extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        $role = Role::admin();
        $acl  = ACL::make('acme');

        $actions = ['manage acme', 'view acme'];

        $acl->actions()->attach($actions);
        $acl->roles()->add($role->name);

        $acl->allow($role->name, $actions);
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        // nothing to do here.
    }
}