QylinFly / role-permission by QylinFly

Permission handling for Laravel 5.x
198
2
3
Package Data
Maintainer Username: QylinFly
Maintainer Contact: 18612116114@163.com (Qylin)
Package Create Date: 2017-02-13
Package Last Update: 2017-03-22
Home Page: https://www.i-vectors.com
Language: PHP
License: MIT
Last Refreshed: 2024-11-24 03:03:30
Package Statistics
Total Downloads: 198
Monthly Downloads: 0
Daily Downloads: 0
Total Stars: 2
Total Watchers: 3
Total Forks: 0
Total Open Issues: 1

Associate users with roles and permissions

init from https://github.com/spatie/laravel-permission

Latest Version on Packagist Build Status SensioLabsInsight Quality Score StyleCI Total Downloads

This package allows to save permissions and roles in a database. It is built upon Laravel's authorization functionality that was introduced in version 5.1.11

Once installed you can do stuff like this:

//adding permissions to a user
$user->givePermissionTo('edit articles');

//adding permissions via a role
$user->assignRole('writer');
$user2->assignRole('writer');

$role->givePermissionTo('edit articles');

You can test if a user has a permission with Laravel's default can-function.

$user->can('edit articles');

If you are using a Laravel version lower than 5.2.28, and want a drop-in middleware to check permissions, check out our authorize package: https://github.com/Qylinfly/laravel-authorize

Install

You can install the package via composer:

$ composer require qylinfly/role-permission

This service provider must be installed.

// config/app.php
'providers' => [
    ...
    Qylinfly\Permission\PermissionServiceProvider::class,
];

You can publish the migration with:

php artisan vendor:publish --provider="Qylinfly\Permission\PermissionServiceProvider" --tag="migrations"

The package assumes that your users table name is called "users". If this is not the case you should manually edit the published migration to use your custom table name.

After the migration has been published you can create the role- and permission-tables by running the migrations:

php artisan migrate

You can publish the config-file with:

php artisan vendor:publish --provider="Qylinfly\Permission\PermissionServiceProvider" --tag="config"

This is the contents of the published config file:

// config/permission.php

return [

    /*
    |--------------------------------------------------------------------------
    | Authorization Models
    |--------------------------------------------------------------------------
    */

    'models' => [

        /*
        |--------------------------------------------------------------------------
        | Permission Model
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | Eloquent model should be used to retrieve your permissions. Of course, it
        | is often just the "Permission" model but you may use whatever you like.
        |
        | The model you want to use as a Permission model needs to implement the
        | `Qylinfly\Permission\Contracts\Permission` contract.
        |
        */

        'permission' => Qylinfly\Permission\Models\Permission::class,

        /*
        |--------------------------------------------------------------------------
        | Role Model
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | Eloquent model should be used to retrieve your roles. Of course, it
        | is often just the "Role" model but you may use whatever you like.
        |
        | The model you want to use as a Role model needs to implement the
        | `Qylinfly\Permission\Contracts\Role` contract.
        |
        */

        'role' => Qylinfly\Permission\Models\Role::class,
    ],

    /*
    |--------------------------------------------------------------------------
    | Authorization Tables
    |--------------------------------------------------------------------------
    */

    'table_names' => [

        /*
        |--------------------------------------------------------------------------
        | Roles Table
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | table should be used to retrieve your roles. We have chosen a basic
        | default value but you may easily change it to any table you like.
        |
        */

        'roles' => 'roles',

        /*
        |--------------------------------------------------------------------------
        | Permissions Table
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | table should be used to retrieve your permissions. We have chosen a basic
        | default value but you may easily change it to any table you like.
        |
        */

        'permissions' => 'permissions',

        /*
        |--------------------------------------------------------------------------
        | User Permissions Table
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | table should be used to retrieve your users permissions. We have chosen a
        | basic default value but you may easily change it to any table you like.
        |
        */

        'user_has_permissions' => 'user_has_permissions',

        /*
        |--------------------------------------------------------------------------
        | User Roles Table
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | table should be used to retrieve your users roles. We have chosen a
        | basic default value but you may easily change it to any table you like.
        |
        */

        'user_has_roles' => 'user_has_roles',

        /*
        |--------------------------------------------------------------------------
        | Role Permissions Table
        |--------------------------------------------------------------------------
        |
        | When using the "HasRoles" trait from this package, we need to know which
        | table should be used to retrieve your roles permissions. We have chosen a
        | basic default value but you may easily change it to any table you like.
        |
        */

        'role_has_permissions' => 'role_has_permissions',

    ],

];

Usage

First add the Qylinfly\Permission\Traits\HasRoles-trait to your User model.

use Illuminate\Foundation\Auth\User as Authenticatable;
use Qylinfly\Permission\Traits\HasRoles;

class User extends Authenticatable
{
    use HasRoles;
    
    // ...
}

This package allows for users to be associated with roles. Permissions can be associated with roles. A Role and a Permission are regular Eloquent-models. They can have a name and can be created like this:

use Qylinfly\Permission\Models\Role;
use Qylinfly\Permission\Models\Permission;

$role = Role::create(['name' => 'writer']);
$permission = Permission::create(['name' => 'edit articles']);

The HasRoles adds eloquent relationships to your models, which can be accessed directly or used as a base query.

$permissions = $user->permissions;
$roles = $user->roles()->pluck('name'); // returns a collection

The HasRoles also adds a scope to your models to scope the query to certain roles.

$users = User::role('writer')->get(); // Only returns users with the role 'writer'

The scope can accept a string, a Qylinfly\Permission\Models\Role-object or an \Illuminate\Support\Collection-object.

###Using permissions A permission can be given to a user:

$user->givePermissionTo('edit articles');

//you can also give multiple permission at once
$user->givePermissionTo('edit articles', 'delete articles');

//you may also pass an array
$user->givePermissionTo(['edit articles', 'delete articles']);

A permission can be revoked from a user:

$user->revokePermissionTo('edit articles');

You can test if a user has a permission:

$user->hasPermissionTo('edit articles');

Saved permissions will be registered with the Illuminate\Auth\Access\Gate-class. So you can test if a user has a permission with Laravel's default can-function.

$user->can('edit articles');

###Using roles and permissions A role can be assigned to a user:

$user->assignRole('writer');

// you can also assign multiple roles at once
$user->assignRole('writer', 'admin');
$user->assignRole(['writer', 'admin']);

A role can be removed from a user:

$user->removeRole('writer');

Roles can also be synced :

//all current roles will be removed from the user and replace by the array given
$user->syncRoles(['writer', 'admin']);

You can determine if a user has a certain role:

$user->hasRole('writer');

You can also determine if a user has any of a given list of roles:

$user->hasAnyRole(Role::all());

You can also determine if a user has all of a given list of roles:

$user->hasAllRoles(Role::all());

The assignRole, hasRole, hasAnyRole, hasAllRoles and removeRole-functions can accept a string, a Qylinfly\Permission\Models\Role-object or an \Illuminate\Support\Collection-object.

A permission can be given to a role:

$role->givePermissionTo('edit articles');

You can determine if a role has a certain permission:

$role->hasPermissionTo('edit articles');

A permission can be revoked from a role:

$role->revokePermissionTo('edit articles');

The givePermissionTo and revokePermissionTo-functions can accept a string or a Qylinfly\Permission\Models\Permission-object.

Saved permission and roles are also registered with the Illuminate\Auth\Access\Gate-class.

$user->can('edit articles');

All permissions of roles that user is assigned to are inherited to the user automatically. In addition to these permissions particular permission can be assigned to the user too. For instance,

$role->givePermissionTo('edit articles');
$user->assignRole('writer');

$user->givePermissionTo('delete articles');

In above example a role is given permission to edit articles and this role is assigned to a user. Now user can edit articles and additionaly delete articles. The permission of 'delete articles' is his direct permission because it is assigned directly to him. When we call $user->hasDirectPermission('delete articles') it returns True and False for $user->hasDirectPermission('edit articles').

This method is useful if one has a form for setting permissions for roles and users in his application and want to restrict to change inherited permissions of roles of user, i.e. allowing to change only direct permissions of user.

###Using blade directives This package also adds Blade directives to verify whether the currently logged in user has all or any of a given list of roles.

@role('writer')
I'm a writer!
@else
I'm not a writer...
@endrole
@hasrole('writer')
I'm a writer!
@else
I'm not a writer...
@endhasrole
@hasanyrole(Role::all())
I have one or more of these roles!
@else
I have none of these roles...
@endhasanyrole
@hasallroles(Role::all())
I have all of these roles!
@else
I don't have all of these roles...
@endhasallroles

You can use Laravel's native @can directive to check if a user has a certain permission.

Multi - project control

use Qylinfly\Permission\Facades\ProjectCodeFactory;
ProjectCodeFactory::setCode('polar');

Using a middleware

The package doesn't contain a middleware to check permissions but it's very trivial to add this yourself.

$ php artisan make:middleware RoleMiddleware

This will create a RoleMiddleware for you, where you can handle your role and permissions check.

// app/Http/Middleware/RoleMiddleware.php
use Auth;

...

public function handle($request, Closure $next, $role, $permission)
{
    if (Auth::guest()) {
        return redirect($urlOfYourLoginPage);
    }

    if (! $request->user()->hasRole($role)) {
       abort(403);
    }
    
    if (! $request->user()->can($permission)) {
       abort(403);
    }

    return $next($request);
}

Don't forget to add the route middleware to your Kernel:

// app/Http/Kernel.php
protected $routeMiddleware = [
    ...
    'role' => \App\Http\Middleware\RoleMiddleware::class,
    ...
];

Now you can protect your routes using the middleware you just set up:

Route::group(['middleware' => ['role:admin,access_backend']], function () {
    //
});

Extending

If you need to extend or replace the existing Role or Permission models you just need to keep the following things in mind:

  • Your Role model needs to implement the Qylinfly\Permission\Contracts\Role contract
  • Your Permission model needs to implement the Qylinfly\Permission\Contracts\Permission contract
  • You must publish the configuration with this command: php artisan vendor:publish --provider="Qylinfly\Permission\PermissionServiceProvider" --tag="config" and update the models.role and models.permission values

Security

If you discover any security related issues, please email 18612116114@163.com instead of using the issue tracker.

Alternatives

License

The MIT License (MIT). Please see License File for more information.