PHPackages                             dlnsk/h-rbac - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Authentication & Authorization](/categories/authentication)
4. /
5. dlnsk/h-rbac

ActiveLibrary[Authentication & Authorization](/categories/authentication)

dlnsk/h-rbac
============

Based on native Laravel's gates and policies. Hierarchical RBAC with callbacks.

v1.2.2(4mo ago)378.3k4MITPHPCI failing

Since Mar 14Pushed 4mo ago3 watchersCompare

[ Source](https://github.com/dlnsk/h-rbac)[ Packagist](https://packagist.org/packages/dlnsk/h-rbac)[ Docs](https://github.com/dlnsk/h-rbac)[ RSS](/packages/dlnsk-h-rbac/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (10)Dependencies (4)Versions (20)Used By (0)

h-rbac
======

[](#h-rbac)

Based on native Laravel's gates and policies. Hierarchical RBAC with callbacks.

[![Latest Version on Packagist](https://camo.githubusercontent.com/2e47ec33fdce45e370d4c12153b64617e233042edd6ebbee35f19627b334cc95/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f762f646c6e736b2f682d726261632e7376673f7374796c653d666c61742d737175617265)](https://packagist.org/packages/dlnsk/h-rbac)[![Software License](https://camo.githubusercontent.com/55c0218c8f8009f06ad4ddae837ddd05301481fcf0dff8e0ed9dadda8780713e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6c6963656e73652d4d49542d627269676874677265656e2e7376673f7374796c653d666c61742d737175617265)](LICENSE.md)[![Coverage Status](https://camo.githubusercontent.com/f319b785ae25a669c83461a624c683cc9f5e33aa3023acfff69a10ddfa173f5c/68747470733a2f2f696d672e736869656c64732e696f2f7363727574696e697a65722f636f7665726167652f672f646c6e736b2f682d726261632e7376673f7374796c653d666c61742d737175617265)](https://scrutinizer-ci.com/g/dlnsk/h-rbac/code-structure)[![Quality Score](https://camo.githubusercontent.com/278430945f333bc4cd71d0d06674cc5394f16c444aedf04a4e96e69f0830266b/68747470733a2f2f696d672e736869656c64732e696f2f7363727574696e697a65722f672f646c6e736b2f682d726261632e7376673f7374796c653d666c61742d737175617265)](https://scrutinizer-ci.com/g/dlnsk/h-rbac)[![Total Downloads](https://camo.githubusercontent.com/64f0fa7ff0f60f794fd01aa6299d03647dc9a74af97de15d44c3f7f3caedd548/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f64742f646c6e736b2f682d726261632e7376673f7374796c653d666c61742d737175617265)](https://packagist.org/packages/dlnsk/h-rbac)

In the process of creating my own projects I have formed an opinion about the minimum required ability of RBAC. It should allow:

- roles and permissions
- callbacks for permissions (for passing parameters in permission checking)
- permission's inheritance (to give different abilities to different roles)
- an optimal way to manage RBAC

Install
-------

[](#install)

> Supports Laravel since v5.1 to the latest (12.\* and above).

Via Composer

```
$ composer require dlnsk/h-rbac
```

Publish some cool stuff:

- config file (config/h-rbac.php) to configure role/permission
- example policy (app/Policies/PostPolicy.php) to configure chains and callbacks

with

```
php artisan vendor:publish --tag=hrbac-config

```

Add permissions, its chains and callbacks to policies.

Add roles and its permissions to config file. That's all!

Overview
--------

[](#overview)

This module is a wrapper for [authorization logic](https://laravel.com/docs/12.x/authorization#creating-policies) and control access to resources of Laravel 5.1 and later.

**Let's describe the minimum required ability of RBAC** (in my opinion).

### Roles and permissions

[](#roles-and-permissions)

It's clear.

### Callbacks for permissions

[](#callbacks-for-permissions)

Very common situation is to allow user to change only his own posts. With this package it's simple:

```
public function editOwnPost($authorizedUser, $post) {
    return $authorizedUser->id === $post->user_id;
}
```

and use as

```
if (\Gate::can('editOwnPost', $post)) {
}
```

You can pass any number of parameters in callback as array.

That's what you can do with Laravel's policies as it described in docs. But Laravel doesn't support roles. Let's see what new adds the module.

### Permission's inheritance

[](#permissions-inheritance)

As you see callbacks are very useful. But what about a site manager who may edit any posts? Create separate permission? But which of them we should check?

Answer is to use chained (inherited) permissions. Example:

`edit` -> `editAnyPost` -> `editPostInCategory` -> `editOwnPost`

Each of these permissions is placed into the appropriate role, but **in code we always check the first** (except in very rare cases):

```
if (\Gate::can('edit', $post)) {
}
```

These permissions in the chain will be checked one by one until one of them will pass. In other case the ability will be rejected for this user. So, we have many permissions with different business logic but are checking in the code only one. This is the key!

### The ways to manage RBAC

[](#the-ways-to-manage-rbac)

It is very popular to use database to store roles and permissions. It flexible but hard to support. Managing of roles and permissions requires the backend.

#### Static roles

[](#static-roles)

Most projects aren't large. It needs only a few roles and permissions, so backend becomes economically inexpedient. Thus, I believe that file driven RBAC is enough for many projects where users can have one or many roles simultaneously. Defining roles in config is visual and simple for support.

By default, roles applied to user store in database, so you should add an accessor to `User` model to get list of roles. Name of attribute you can change in `config/h-rbac.php` if you need.

```
public function getRolesAttribute() {
    return $this->roles()->pluck('name')->toArray();
}
```

It doesn't matter how you store roles. Just return an array from function. You also can write and bind your own `RolesProvider` through `DI`.

#### Static roles + overriding permissions

[](#static-roles--overriding-permissions)

Some projects may suppose that administrator can override some user's permissions (include or exclude). If you have dozens of such users it's hard to make different roles for each. So overriding is a good choice.

It requires additional database table to store overrides. Publish migration with

```
php artisan vendor:publish --tag=hrbac-migrations

```

bind `EloquentPermissionProvider` inside your `AppServiceProvider.php` bindings:

```
public $bindings = [
    PermissionsProvider::class => EloquentPermissionProvider::class,
    ...
];
```

and add trait `WithPermissions` to your `User` model

```