DEV Community: Nikolya May

ABAC in Laravel 13: permissions that look at your data

Nikolya May — Tue, 13 Oct 2026 11:30:15 +0000

Download the sample code: https://github.com/wnikk/-laravel-access-example

This is the second part. The first one, How to use Access Control Rules and CRUD in Laravel (tutorial step by step), built roles and permissions: RBAC.
This one goes further: permissions that look at the data. That is ABAC, Attribute-Based Access Control, and it arrived in version 3.x of "wnikk/laravel-access-rules".

You do not need the first part to follow this one. Everything is built from scratch.

What we had in 2.x

A short reminder, in case you skipped part one:

a rule is a name of something that can be permitted, orders.view;
an owner holds permissions: a user, a role, a group;
owners inherit from each other, which is how roles work;
an option splits one rule into several, profile.update.email;
the magic suffix .self means "only the author of the record".

All of it still works in 3.x, with the same tables and the same methods.

And here is what it could not say:

"a manager sees orders over 100 with fewer than 3 items";
"only orders of my department";
"everything, except clients from Paris";
and the hardest one: "show me the list of what I am allowed to see".

In 2.x each of these meant a policy class and a hand-written query, and the two had to agree forever.
In 3.x each of them is one line.

$role->addPermission('orders.view', when: 'order.cost > 100 && order.items.count < 3');

$user->can('orders.view', $order);            // one record
Order::allowedTo('orders.view')->paginate();  // the list, filtered by the database

Where will we start?

We build a tiny back office of a shop:

Orders with items, a client, a category and products.
Two users, Ann and Bob, a role and two teams.
Eighteen short examples. Each adds one idea and shows its result on the same six orders.

The data is small on purpose: you can check every result by eye.

Step 1: Create Laravel application

Version 3 works on Laravel 13 and PHP 8.4 or after.

composer create-project laravel/laravel abac-example

Step 2: Install the package

composer require wnikk/laravel-access-rules
php artisan vendor:publish --tag=access-config --tag=access-migrations

Step 3: Tell the package who and what

File config/access.php. Three lists matter today:

// who can hold permissions
'owner_types' => [
    App\Models\User::class,
    'Role',
    'Team',
],

// models that conditions may read, by the name they have in conditions
'resources' => [
    'order'    => App\Models\Order::class,
    'client'   => App\Models\Client::class,
    'item'     => App\Models\Item::class,
    'category' => App\Models\Category::class,
    'product'  => App\Models\Product::class,
],

// owner types that work as a tenant, see Example 9
'tenant_types' => ['Team'],

resources is a whitelist. A condition can come from an admin panel, and it can only touch models listed here.

Step 4: Migrations

php artisan make:migration create_shop_tables

public function up(): void
{
    Schema::table('users', function (Blueprint $table) {
        $table->integer('department_id')->default(1);
        $table->integer('approval_limit')->default(0);
    });
    Schema::create('clients', function (Blueprint $table) {
        $table->id();
        $table->string('name');
        $table->string('city')->nullable();
        $table->integer('team_id');
    });
    Schema::create('categories', function (Blueprint $table) {
        $table->id();
        $table->integer('parent_id')->nullable();
        $table->string('name');
    });
    Schema::create('products', function (Blueprint $table) {
        $table->id();
        $table->string('name');
        $table->boolean('restricted')->default(false);
    });
    Schema::create('orders', function (Blueprint $table) {
        $table->id();
        $table->string('number');
        $table->integer('client_id')->nullable();
        $table->integer('user_id');            // the author
        $table->integer('department_id');
        $table->integer('category_id');
        $table->integer('cost');
        $table->integer('budget')->nullable();
        $table->string('status');
        $table->boolean('locked')->default(false);
        $table->dateTime('created_at');
    });
    Schema::create('items', function (Blueprint $table) {
        $table->id();
        $table->integer('order_id');
        $table->integer('price');
    });
    Schema::create('order_product', function (Blueprint $table) {
        $table->integer('order_id');
        $table->integer('product_id');
        $table->integer('quantity')->default(1);
    });
}

php artisan migrate

Step 5: Models

The user gets the usual trait:

use Wnikk\LaravelAccessRules\Traits\HasPermissions;

class User extends Authenticatable
{
    use HasPermissions;

The order gets a new one. It adds allowedTo(), the filter of lists:

use Wnikk\LaravelAccessRules\Traits\HasAccessScope;

class Order extends Model
{
    use HasAccessScope;

    public $timestamps = false;
    protected $guarded = [];
    protected $casts = ['locked' => 'boolean'];

    public function client(): BelongsTo     { return $this->belongsTo(Client::class); }
    public function category(): BelongsTo   { return $this->belongsTo(Category::class); }
    public function items(): HasMany        { return $this->hasMany(Item::class); }
    public function products(): BelongsToMany
    {
        return $this->belongsToMany(Product::class)->withPivot('quantity');
    }
}

Important: relations declare their return type. That is how the package knows client is a relation. It never calls a method to find out, because the method could be delete().

Client, Item, Product are plain models. Category points at itself:

class Category extends Model
{
    public function parent(): BelongsTo { return $this->belongsTo(self::class, 'parent_id'); }
}

Step 6: Data

Seed it any way you like. This is what the examples expect. "Today" is a Friday, 12:00.

Users

id	name	department_id	approval_limit
1	Ann	1	500
2	Bob	2	100

Clients: 1 Acme (Berlin, team 1), 2 Bolt (Paris, team 1), 3 Core (Berlin, team 2), 4 Dune (no city, team 2)

Categories: 1 Electronics → 2 Phones, 3 Laptops; 4 Furniture

Products: 1 Phone, 2 Charger, 3 Battery pack (restricted)

Orders

id	number	client	author	dept	category	cost	budget	status	locked	created	items	products × quantity
1	EU-1001	Acme	Ann	1	Phones	150	200	draft		today 08:00	100, 50	Phone ×1, Charger ×2
2	EU-1002	Bolt	Ann	1	Laptops	900	800	review		10 days ago	300, 300, 200, 100	Battery pack ×5
3	US-2001	Core	Bob	2	Furniture	50	100	paid		today 11:00	50
4	EU-1003	Dune	Bob	1	Electronics	450	600	draft	yes	yesterday	450	Phone ×1, Battery pack ×1
5	US-2002	Acme	Bob	2	Phones	120		draft		20 days ago
6	EU-1004	none	Ann	2	Furniture	700	700	review		today 00:30	400, 200, 100	Charger ×10

Step 7: Rules, a role and two teams

php artisan make:seeder AccessSeeder

use Wnikk\LaravelAccessRules\Facades\Access;

public function run(): void
{
    // "resource" says which model the rule is about
    Access::newRule('orders.view', 'View orders', resource: 'order');
    Access::newRule('orders.approve', 'Approve orders', resource: 'order');

    Access::for('Role', 'manager')->create('Managers');
    Access::for('Team', 1)->create('North');
    Access::for('Team', 2)->create('South');

    User::find(1)->inheritPermissionFrom('Team', 1);   // Ann is in team North
    User::find(2)->inheritPermissionFrom('Team', 2);   // Bob is in team South
}

Access::for(...) is new in 3.x: a short way to work with an owner that has no model.

One helper route, for this tutorial only, to switch users:

Route::get('/login-as/{id}', fn ($id) => Auth::loginUsingId($id) ? redirect('/orders') : abort(404));

Let's move on to the most interesting part ☕

Every example gives Ann or Bob one permission and shows which of the six orders it opens.
To try the next one, take the previous permission away: $user->remPermission('orders.view');

Example 1

The first condition. A value of a column and a count of related records:

$ann->addPermission('orders.view', when: 'order.cost > 100 && order.items.count < 3');

Check one record, the usual Laravel way:

class OrderController extends Controller
{
    public function show(Order $order)
    {
        Gate::authorize('orders.view', $order);

        return Response::json($order);
    }
}

Result: orders 1, 4, 5 open. Order 2 costs enough but has four items. Order 3 is too cheap.

A mistake in a condition does not wait for a user to find it. It stops you when you save:

$ann->addPermission('orders.view', when: 'order.itms.count < 3');
// InvalidConditionException: "itms" in "order.itms.count" is not a relation of App\Models\Order
// the same for an unknown model (invoice.cost) and an unknown function (yesterday())

A mistyped column is the one thing saving lets through, because a model may have it as an accessor. Example 15 catches those.

Example 2

Now the list. No new rule, no new query, the same permission:

public function index()
{
    return Response::json(Order::allowedTo('orders.view')->orderBy('id')->paginate());
}

The condition became a part of WHERE:

select * from "orders" where (
  "orders"."cost" > ?
  and (select count(*) from "items" where "orders"."id" = "items"."order_id") < ?
)

One query. Pagination, sorting and your own where() work as always.

The list and the single check always agree. You will never show a row that answers 403 when clicked.

Example 3

Compare a record with the user:

$ann->addPermission('orders.view', when: 'order.department_id == user.department_id');

Ann (department 1) sees 1, 2, 4. Give Bob the same line and he sees 3, 5, 6. One permission, a different result for each user. So it belongs on a role:

Access::for('Role', 'manager')->allow('orders.approve',
    when: 'order.cost <= user.approval_limit && order.user_id != user.id');

$ann->inheritPermissionFrom('Role', 'manager');

"Approve up to your limit, but never your own order." Ann (limit 500) may approve 3, 4, 5.

user. is any attribute of your User model. Plus user.id, user.tenant (Example 9) and user.guest.

Example 4

Walk through a relation:

$ann->addPermission('orders.view', when: "order.client.city != 'Paris'");

Result: 1, 3, 5. Order 2 is from Paris, and orders 4 and 6 are missing too.

Client of order 4 has no city. Order 6 has no client. A comparison with NULL is unknown, as in SQL, and a permission with an unknown condition does not apply.

Say it out loud when you mean such records too:

$ann->addPermission('orders.view', when: "order.client.city == null || order.client.city != 'Paris'");

Result: 1, 3, 4, 5, 6.

Example 5

Prohibitions, and who wins. The priority has five steps, from weak to strong:

nothing is said: not permitted
inherited permission
inherited prohibition
own permission
own prohibition

Watch it work, line by line:

Access::for('Role', 'manager')->allow('orders.view');                       // Ann sees 1 2 3 4 5 6
Access::for('Role', 'manager')->deny('orders.view', when: 'order.locked');  // Ann sees 1 2 3 5 6
$ann->addPermission('orders.view', when: 'order.cost > 400');               // Ann sees 1 2 3 4 5 6
$ann->addProhibition('orders.view', when: "order.status == 'paid'");        // Ann sees 1 2 4 5 6

Look at the third line. The role hides locked orders from all its members. Ann's own permission is stronger, so she gets order 4 back. No need to clone the role for one person.

A prohibition takes a permission away and vetoes nothing. Your Gate::before for a super administrator, your policies and other packages keep their word, as in 2.x.

Example 6

Sometimes there is no record yet. A menu item, a "New order" button. There are three ways to ask:

$user->can('orders.view', $order);         // this order
$user->can('orders.view', Order::class);   // orders in general: is there any order I may see?
$user->can('orders.view');                 // nothing to look at: only permissions without a condition count

With the permission of Example 1, the second line is true and the third is false.

@can('orders.view', App\Models\Order::class)
    <a href="/orders">Orders</a>
@endcan

authorizeResource() passes the class for index and create by itself.

Example 7

Aggregates over related records: count, sum, min, max, exists. Each can take a filter:

'sum(order.items.price) <= user.approval_limit'     // Ann: 1, 3, 4, 5      Bob: 3, 5
'exists(order.items, price >= 300)'                 // 2, 4, 6

Inside a filter, names without a prefix are columns of the related model.

And time:

"order.created_at >= ago('7 days')"                 // 1, 3, 4, 6

Also now(), today(), after('3 days'), monthStart(-1), yearStart(). A permission that expires by itself, without a cron job.

Example 8

Arithmetic, ranges and text:

'order.cost * 1.2 > order.budget'                   // 2, 6      over budget with 20% on top
'order.cost between 100 and 500'                    // 1, 4, 5   both ends included
"startsWith(order.number, 'EU-')"                   // 1, 2, 4, 6
"lower(order.client.city) == 'berlin'"              // 1, 3, 5

Also endsWith(), contains(), + - * / and brackets. Text functions are exact, letter case included, on every database. Use lower() on both sides to ignore case.

Example 9

Teams, or tenants. Step 3 set 'tenant_types' => ['Team'], Step 7 created two teams.
A user that inherits from teams gets their ids as the list user.tenant:

Access::for('Role', 'manager')->allow('orders.view', when: 'order.client.team_id in user.tenant');

Ann (North) sees 1, 2, 5. Bob (South) sees 3, 4. Move a user to another team and the list follows. There is no role per team and nothing to keep in sync.

Example 10

Trees. "Electronics and everything under it":

$ann->addPermission('orders.view', when: "order.category_id in belowOrSelf('category.name', 'Electronics')");

Result: 1, 2, 4, 5. Phones and Laptops came along, Furniture stayed out.

There are four of them: below, belowOrSelf, above, aboveOrSelf. The tree is walked once per request, and the database receives a plain category_id in (1, 2, 3).

Example 11

Many-to-many, with columns of the pivot table:

'not exists(order.products, restricted)'            // 1, 3, 5, 6   no dangerous goods inside
'exists(order.products, pivot.quantity >= 5)'       // 2, 6         wholesale
'sum(order.products.pivot.quantity) >= 3'           // 1, 2, 6

The relation has to load the column, ->withPivot('quantity'). We did that in Step 5. Forget it, and the condition is refused when you save it, with a hint.

Polymorphic relations (morphMany, morphToMany, morph map) need nothing special. They work the same way, see Example 18.

Example 12

The environment, and guests:

Access::for('Role', 'manager')->allow('orders.approve',
    when: 'env.weekday in [1, 2, 3, 4, 5] && env.hour between 9 and 18');

Also env.ip, env.now, env.today, env.app. Such a part is computed before the query: on a Saturday the database gets WHERE 0 = 1 and does not read a single row.

Visitors without a login are checked as one owner, named in config:

'guest' => ['type' => 'Role', 'id' => 'guest'],

Access::for('Role', 'guest')->create('Guests');
Access::for('Role', 'guest')->allow('catalog.view');

Gate::forUser(null)->allows('catalog.view');   // true

Example 13

Two things for people who dislike strings. Names of rules as an enum:

enum Ability: string
{
    case OrdersView = 'orders.view';
}

$ann->addPermission(Ability::OrdersView, when: 'order.cost > 100');
$ann->can(Ability::OrdersView, $order);
Order::allowedTo(Ability::OrdersView)->get();

And conditions built in code. The result is the same as from text:

use Wnikk\LaravelAccessRules\Conditions\Cond;

$ann->addPermission('orders.view', when: Cond::all(
    Cond::attr('order.cost')->gt(100),
    Cond::count('order.items')->lt(3),
));

Example 14

The question every access system hears most: "why can't I see it?"
Take the four lines of Example 5 and ask:

php artisan acr:explain "App\Models\User" 1 orders.view order:3

orders.view for User 1, asked about a record: PROHIBITED
=> prohibit, own: User 1 (Ann), rule orders.view, when order.status == 'paid' -> true
 2 permit, own: User 1 (Ann), rule orders.view, when order.cost > 400 -> not reached
 3 prohibit, inherited: Role manager (Managers), rule orders.view, when order.locked == true -> not reached
 4 permit, inherited: Role manager (Managers), rule orders.view -> not reached
   order.status = "paid"

Every permission that takes part, strongest first. The arrow marks the one that decided, and you see the value it read.

On production it is even simpler. An administrator looks at the application as the user who complains, and the application turns debug mode on for that request:

// a middleware of your application
if (session('impersonated_by') && $request->cookie('access_debug')) {
    Access::debug();
}

Now every refusal is explained and every filtered list is written down. The mode only watches: it changes no decision and no message.

Access::debugLog();
// 'denials' => every refused check, explained; the text from above is under 'text'
// 'lists'   => every allowedTo(): the conditions it used, and the SQL they became

Print the last one on your 403 page:

@if ($denial = last(Access::debugLog()['denials']))
    <pre>{{ $denial['text'] }}</pre>
@endif

Keep it off for ordinary users. An explanation shows rules of other people.

Example 15

Conditions are checked when you save them. Then the application changes. Somebody renames cost to total in a migration, and stored conditions still say cost.

php artisan acr:lint

| permission #21 of Role manager for orders.approve | "cost" is not a column of table "orders": ... a list cannot filter by it |
| permission #21 of Role manager for orders.approve | types of columns have changed since the condition was saved ... run "php artisan acr:lint --fix" |
2 problem(s) found.

It exits with code 1. Put it into your CI and after migrate in the deploy script. The second line is the same
column seen from another side: the stored condition remembers the type of cost, and --fix saves it again once the
column is back.

Example 16

Two small things for real projects.

A seeder that grants hundreds of permissions drops the cache once, not hundreds of times:

Access::batch(function () use ($users) {
    foreach ($users as $user) {
        $user->inheritPermissionFrom('Role', 'manager');
    }
});

And every change fires one event. An audit log is a listener:

use Wnikk\LaravelAccessRules\Events\AccessChanged;

Event::listen(AccessChanged::class, function (AccessChanged $event) {
    Log::channel('audit')->info($event->action, $event->details + ['by' => auth()->id()]);
});

$event->action is permission.granted, permission.revoked, inheritance.added and so on. $event->details says for whom, which rule and with what condition.

By the way, about speed. After the first check of a request, a check runs no queries and takes a few microseconds. Version 2 ran a query per check.

Example 17

This one is for the world outside of Laravel. XACML 3.0 is the standard language of access policies. Auditors ask for it, other systems speak it.

php artisan acr:xacml:export storage/app/access.xml

One file: a valid XACML policy, and at its end a policy set no request reaches, with what XACML has no place for: titles of rules, names of owners, inheritance.

And back. Look first, import second:

php artisan acr:xacml:import storage/app/access.xml --check

| Kind       | Action  | What                                 | Document         | Database          |
| permission | differs | App\Models\User:1 may orders.view    | order.cost > 400 | order.cost > 1000 |
rule: 1 same
owner: 2 same
permission: 3 same, 1 differs
inheritance: 1 same

Nothing was written. You see what an import would create, and what differs from the database. Then:

php artisan acr:xacml:import storage/app/access.xml            # creates what is missing
php artisan acr:xacml:import storage/app/access.xml --replace  # and brings what differs to the document

It also reads policies written by other systems. What it cannot convert, it reports with an address in the document and writes nothing, because a lost prohibition means wider access.

The same from a controller, streamed to the browser:

use Wnikk\LaravelAccessRules\Xacml\Xacml;

public function download(Xacml $xacml)
{
    return response()->streamDownload(fn () => $xacml->export('php://output'), 'access.xml', ['Content-Type' => 'application/xml']);
}

public function preview(Request $request, Xacml $xacml)
{
    return view('access.import', ['report' => $xacml->check($request->file('policy'))]);
}

Example 18

The last one is about polymorphic relations. A tag hangs on a product and on a category alike: morphToMany
and a morph map. Example 11 said they need nothing special. Two tables, added for this example only:

Schema::create('tags', function (Blueprint $table) {
    $table->id();
    $table->string('name');
});
Schema::create('taggables', function (Blueprint $table) {   // a tag on a product or on a category
    $table->integer('tag_id');
    $table->morphs('taggable');
});

The product gets the relation, with its return type as in Step 5. The morph map goes to AppServiceProvider::boot(),
and Tag is a plain model listed in resources of config/access.php as 'tag' => App\Models\Tag::class:

class Product extends Model
{
    use HasAccessScope;

    public function tags(): MorphToMany { return $this->morphToMany(Tag::class, 'taggable'); }
}

Relation::enforceMorphMap(['product' => Product::class, 'category' => Category::class]);

Data. Phone is tagged sale and new, Charger sale, Battery pack new. And the category Laptops, id 3, is
tagged sale: it shares its id with the Battery pack, so a subquery that forgot the morph type would let the Battery pack in.

Access::newRule('products.view', 'View products', resource: 'product');
$ann->addPermission('products.view', when: "exists(product.tags, name == 'sale')");            // Phone, Charger

$ann->addPermission('orders.view', when: "exists(order.products, exists(tags, name == 'sale'))");   // orders 1, 4, 6

The second line reads the tags from the other side: orders that hold a product on sale. Order 2 holds only the Battery pack.

select * from "products" where exists (
  select 1 from "tags" inner join "taggables" on "tags"."id" = "taggables"."tag_id"
  where "products"."id" = "taggables"."taggable_id" and "taggables"."taggable_type" = ? and "tags"."name" = ?)
-- bindings: ["product", "sale"]

The package writes no joins of its own. For every relation in a condition it asks Eloquent for the subquery that
whereHas() builds, so the pivot table, the morph type and the morph map come along. morphMany works the same way.
The one relation the package refuses is morphTo: its far end is a different model for every row, so no single
subquery describes it. Ask from the other side, exists(product.tags, ...) instead of tag.taggable.

Coming from 2.x?

Nothing has to be converted. Tables, names of rules, options, .self, the trait and the console commands stay compatible.

composer require wnikk/laravel-access-rules:^3.0
php artisan vendor:publish --tag=access-migrations-upgrade
php artisan migrate

The migration adds a few columns and renames rules that 2.x had soft deleted. One thing to check by hand: delRule() in down() of your migrations now needs true to delete a rule that is still granted. The details are in the upgrade guide.

From the author: against Spatie and Bouncer, with numbers this time

Part one listed what set 2.x apart, and every point still holds in 3.x: a permission goes to a user, a group, a role or a plain name without a model, so users of an API or of a directory service need no table of their own; inheritance has no depth limit and runs between owners of any kind; a prohibition inherits like a permission and loses to an own permission; ownership is the suffix .self.

What 3.x added, the other two do not have; the table lists the differences only:

	this package	Spatie	Bouncer
Roles inherit from roles	any depth	no, roles are flat	no
Prohibitions	yes, five-step priority	no	yes
Owners without a model	yes	no	no
Permission depends on data of the record	columns, relations, aggregates, the user, time	no, write a policy	ownership and single instances
Lists filtered by the same rules, in SQL	`allowedTo()`	no	no
Why a check refused	`acr:explain`, debug mode	no	no
Stored rules checked against models	`acr:lint`	no	no
XACML export and import	yes	no	no
Teams / tenants	inheritance and `user.tenant`	teams	scopes

The cost of a check comes from one run on one machine: a Laravel 13 application with the three packages installed, the same data for each, MySQL, 2 000 abilities, 20 roles, a user who holds 500 permissions, 5 000 other users, one request of a signed-in user through Gate::allows(). Three runs, the median:

	this package	Spatie	Bouncer
first check of a request	0.2 ms, 0 queries, 51 KB	5.0 ms, 2 queries, 3.9 MB	4.2 ms, 0 queries
next check, permitted	4.0 µs	28.9 µs	4 169 µs
next check, not permitted	4.1 µs	1 461 µs	4 198 µs
a page with 50 checks	0.2 ms	2.5 ms	207 ms

The design explains the numbers. A request loads the permissions of one owner, compiled once; every check after the first reads memory, so the cost does not grow with the size of the application. Spatie loads the whole list of permissions on every request and looks a name up in it, which is the 3.9 MB and the 5 ms. Bouncer reads the abilities of the user from the cache store on every check, a file read or a network round trip each time. The third line of the table matters in every application that also uses policies: Gate::before of a permission package runs for every ability, $user->can('update', $post) included, so a slow "not permitted" is paid on checks that have nothing to do with permissions.

Versions, the method and what these numbers do not say are in Performance, with the way to repeat the run in an empty application. Spatie and Bouncer do RBAC and have years of use behind them; pick this package when access depends on data, when lists must follow the same rules, or when the cost of a check matters.

Final words

We started with roles in part one. Now a permission can look at a column, at the user, at a related record, at a sum over a relation, at a tree, at the clock, through a polymorphic relation. And every one of them filters a list with the same line of text.

Where to go next:

Conditions: the whole language on one page
Basic usage: rules, roles, options, cache, console
XACML: what is exported and how foreign policies convert

The package: wnikk/laravel-access-rules on GitHub and Packagist. An administration panel for it, with the editor of conditions, the explanation of a check and XACML in the browser, is wnikk/laravel-access-ui.

If something in the examples does not answer the way the article says, open an issue: every example here is also a test of the package.

How use Access Control Rules and GRUD in Laravel 12 (Tutorial step by step)

Nikolya May — Wed, 29 Mar 2023 14:28:44 +0000

Download the sample code: https://github.com/wnikk/-laravel-access-example

In this article, we'll dive into how to implement Role-Based Access Control (RBAC) in Laravel 12 or from Laravel 8 and above, to manage user access effectively.
RBAC is a security model where users are assigned roles based on their job responsibilities and access rights are granted to these roles.
This methodology ensures that only authorized users have access to specific functionalities and data within the application.
To implement RBAC, we'll be using a package "wnikk/laravel-access-rules" from Github that simplifies the creation of roles and permissions.
We'll cover the steps involved in creating roles and permissions, assigning them to users, and protecting sensitive information from unauthorized access.

One of the primary advantages of implementing RBAC in Laravel is that it enables granular access control.
With RBAC, you can define roles for different job positions, which restrict access to features and data within the application.
For example, you can create an "admin" role with full access to the application, while a "guest" role might only be able to view certain pages.
You can also create custom roles that have access to specific functionalities, such as "content manager" or "billing specialist."
This way, users only have access to the functionalities they need to perform their job duties.

To create RBAC in Laravel, we'll be using a composer "wnikk/laravel-access-rules" package that provides a simple and flexible way to create roles and permissions.
This package allows us to assign roles to users, assign permissions to roles, and assign permissions directly to users.
We'll cover the steps involved in setting up the package, defining roles and permissions, and assigning them to users.
By following this step-by-step guide, you can easily implement RBAC in your Laravel application and ensure the security of your user accounts.

Where will we start?

To simplify the process of implementing Laravel permission:

User Management - We create user management using Laravel 10. This allows for easier application of Laravel permission.
Rules Management - Additionally, we implement rules management to limit access to content by defining a list of rules for the project.
Permits and inheritance Management - Permissions management can be used to add roles to user accounts and assign Laravel permission to them.
News Management - Finally, we can implement news management and apply Laravel permission with each role assigned to a user.

We'll also be utilizing CRUD functionality, which refers implement a persistent application: create, read, update, and delete.
We'll apply CRUD to all the models in our project to allow for easy management of data.

If you're looking for examples of the concepts discussed in this article, you can find them readily available in the corresponding GitHub repository. Simply navigate to the repository and browse through the source code to see how the various implementations have been carried out. This will provide you with a better understanding of how the concepts work in practice and how you can apply them to your own projects.

Step 1: Create Laravel application

To begin implementing Laravel 11, the first step is to create a new Laravel application. To do this, open up your terminal or command prompt and initiate the creation of a new Laravel application. By following this step, you'll be on your way to implementing Laravel 11 and all of its features in your web application:

composer create-project laravel/laravel rules-example

Step 2: Install Packages

Next, we'll need to install the required Wnikk package for Access Control Rules (ACR) and a visual control package. This can easily be done by opening up your terminal and executing the commands provided below.

composer require wnikk/laravel-access-rules
composer require wnikk/laravel-access-ui

To make changes to the Wnikk package, we'll need to run a command that generates configuration files, migration files, and view files. By following this step, you'll be able to customize the package to meet the specific requirements of your Laravel application:

php artisan vendor:publish --provider="Wnikk\\LaravelAccessRules\\AccessRulesServiceProvider"
php artisan vendor:publish --provider="Wnikk\\LaravelAccessUi\\AccessUiServiceProvider"

Step 3: Update User Model

We will now integrate ACR with our existing user model. This step is important to ensure that our Laravel application has proper access control in place We just need to add HasPermissions trait in it:

use Wnikk\LaravelAccessRules\Traits\HasPermissions;

class User extends Model {
    // The User model requires this trait
    use HasPermissions;

Step 4: Configure database connection

For the purpose of this example, we'll be using an SQLite file database. To get started, create an empty file named './database/database.sqlite' and configure the database connection as shown in the example provided.
File .env:

DB_CONNECTION=sqlite

At this point, we're ready to run the migration command. By executing this command, we'll be able to create the necessary tables in our SQLite file database, allowing for efficient data management.

php artisan migrate

Now that we have implemented a working access control system with the ACR package, the next step is to add permissions to the models in our application. Permissions specify what actions a user with a certain role can perform on a particular resource.

Step 5: Create News Migration

Moving forward, our next step will be to create a migration for the news table. To accomplish this task, execute the following command, which will generate the necessary file and allow us to define the table schema:

php artisan make:migration create_news_table

This will create a new migration file in the database/migrations directory of our Laravel application. Below you'll find the complete code necessary to define the table's structure, including the various fields and their corresponding types:

<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::create('news', function (Blueprint $table) {
            $table->id();
            $table->timestamps();
            $table->integer('user_id');
            $table->string('name', 70);
            $table->string('description', 320)->nullable();
            $table->text('body');
            $table->softDeletes();
        });
    }
    public function down(): void
    {
        Schema::dropIfExists('news');
    }
};

We will now re-run the migration:

php artisan migrate

Step 6: Create model

Now, we will create a news model to retrieve data from the news table. To generate the news model, simply run the following Artisan command. This will create the news model in the app\Models directory.

php artisan make:model News

Example of code for News model:

<?php
namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes;

/**
 * Class News
 *
 * @property $id
 * @property $user_id
 * @property $name
 * @property $description
 * @property $body
 */
class News extends Model
{
    use HasFactory, SoftDeletes;

    protected $fillable = [
        'user_id',
        'name',
        'description',
        'body',
    ];
}

Step 7: Create Seeder

Now that we have all the required tables in our database, it's time to fill them with test data and set up rules for them.

1. Create a few new users:

php artisan make:seeder CreateUserSeeder

Source file database\seeders\CreateUserSeeder.php:

<?php
namespace Database\Seeders;

use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Str;

class CreateUserSeeder extends Seeder
{
    /**
     * Run the database seeds.
     */
    public function run(): void
    {
        DB::table('users')->insert([
            'id' => 1,
            'name' => 'Test user 1',
            'email' => 'root@mail.com',
            'password' => Hash::make('12345'),
        ]);
        DB::table('users')->insert([
            'id' => 2,
            'name' => 'Test user 2',
            'email' => 'test@mail.com',
            'password' => Hash::make('password'),
        ]);
        DB::table('users')->insert([
            'name' => 'Test user 3',
            'email' => Str::random(10).'@mail.com',
            'password' => Hash::make(Str::random(10)),
        ]);
        DB::table('users')->insert([
            'name' => 'Test user 4',
            'email' => Str::random(10).'@mail.com',
            'password' => Hash::make(Str::random(10)),
        ]);
        DB::table('users')->insert([
            'name' => 'Test user 5',
            'email' => Str::random(10).'@mail.com',
            'password' => Hash::make(Str::random(10)),
        ]);
    }
}

2. We create multiple news entries.

php artisan make:seeder NewsTableSeeder

Source file database\seeders\NewsTableSeeder.php:

<?php
namespace Database\Seeders;

use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;
use App\Models\News;

class NewsTableSeeder extends Seeder
{
    public function run(): void
    {
        News::create([
            'user_id' => 1,
            'name' => 'First news',
            'description' => 'Description of first news',
            'body' => 'Body content 1...',
        ]);
        News::create([
            'user_id' => 1,
            'name' => 'Second news',
            'description' => 'Description of second test news',
            'body' => 'Body content 2...',
        ]);
        News::create([
            'user_id' => 2,
            'name' => 'News of test user',
            'body' => 'Body content 3...',
        ]);
    }
}

3. Multiple rules will be added to the system for testing purposes.

php artisan make:seeder CreateRulesSeeder

The rules themselves:
Source file database\seeders\CreateRulesSeeder.php:

<?php
namespace Database\Seeders;

use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;
use Wnikk\LaravelAccessRules\AccessRules;

class CreateRulesSeeder extends Seeder
{
    public function run(): void
    {
        // example #1 - route middleware
        AccessRules::newRule('example1.viewAny', 'View all users on example1');

        // example #2 - check in action
        AccessRules::newRule('example2.view', 'View data of user on example2');

        // example #3 - check on action options
        AccessRules::newRule([
            'guard_name' => 'example3.update',
            'title' => 'Changing different user data on example3',
            'options' => 'required|in:name,email,password'
        ]);

        // example #4 - global resource
        AccessRules::newRule('viewAny', 'Global rule "viewAny" for example4');
        AccessRules::newRule('view', 'Global rule "view" for example4');
        AccessRules::newRule('create', 'Global rule "create" for example4');
        AccessRules::newRule('update', 'Global rule "update" for example4');
        AccessRules::newRule('delete', 'Global rule "delete" for example4');

        // example #5 - resource for controller
        AccessRules::newRule('Examples.Example5.viewAny', 'Rule for one Controller his action "viewAny" example5');
        AccessRules::newRule('Examples.Example5.view', 'Rule for one Controller his action "view" example5');
        AccessRules::newRule('Examples.Example5.create', 'Rule for one Controller his action "create" example5');
        AccessRules::newRule('Examples.Example5.update', 'Rule for one Controller his action "update" example5');
        AccessRules::newRule('Examples.Example5.delete', 'Rule for one Controller his action "delete" example5');

        // example #6 - magic self
        AccessRules::newRule(
            'example6.update',
            'Rule that allows edit all news',
        'An example of how to use a magic suffix ".self" on example6'
        );
        AccessRules::newRule('example6.update.self', 'Rule that allows edit only where user is author');

        // example #7 - Policy
        AccessRules::newRule('Example7News.test', 'Rule event "test" example7');

        // Final example, add control to the Access user interface
        $id = AccessRules::newRule('Examples.UserRules.main', 'View all rules, permits and inheritance');
        AccessRules::newRule('Examples.UserRules.rules', 'Working with Rules', null, $id, 'nullable|in:index,store,update,destroy');
        AccessRules::newRule('Examples.UserRules.roles', 'Working with Roles', null, $id, 'nullable|in:index,store,update,destroy');
        AccessRules::newRule('Examples.UserRules.inherit', 'Working with Inherit', null, $id, 'nullable|in:index,store,destroy');
        AccessRules::newRule('Examples.UserRules.permission', 'Working with Permission', null, $id, 'nullable|in:index,update');
    }
}

4. We are now creating the super administrator role.

From which all other user roles will inherit. In this step, it's essential to set the three types of models that can have permissions in the default settings file (config/access.php) groups, roles, and users. For the super administrator, we will use roles:

php artisan make:seeder CreateRootAdminRoleSeeder

Permits for each model can be controlled through an owner associated with it.
Source file database\seeders\CreateRootAdminRoleSeeder.php:

<?php
namespace Database\Seeders;

use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;
use Wnikk\LaravelAccessRules\AccessRules;

class CreateRootAdminRoleSeeder extends Seeder
{
    public function run(): void
    {
        $acr = new AccessRules;
        $acr->newOwner('Role', 'root', 'RootAdmin role');

        // For example #1
        $acr->addPermission('example1.viewAny');

        // For example #2
        $acr->addPermission('example2.view');

        // For example #3
        $acr->addPermission('example3.update', 'name');
        $acr->addPermission('example3.update', 'email');
        $acr->addPermission('example3.update', 'password');

        // For example #4
        $acr->addPermission('viewAny');
        $acr->addPermission('view');
        $acr->addPermission('create');
        $acr->addPermission('update');
        $acr->addPermission('delete');

        // For example #5
        $acr->addPermission('Examples.Example5.viewAny');
        $acr->addPermission('Examples.Example5.view');
        $acr->addPermission('Examples.Example5.create');
        $acr->addPermission('Examples.Example5.update');
        $acr->addPermission('Examples.Example5.delete');

        // For example #6
        //For all - $acr->addPermission('example6.update');
        $acr->addPermission('example6.update.self');

        // For example #7
        $acr->addPermission('Example7News.test');

        // For final example
        $acr->addPermission('Examples.UserRules.index');
        $acr->addPermission('Examples.UserRules.rules');
        $acr->addPermission('Examples.UserRules.rules', 'index');
        $acr->addPermission('Examples.UserRules.rules', 'store');
        $acr->addPermission('Examples.UserRules.rules', 'update');
        $acr->addPermission('Examples.UserRules.rules', 'destroy');
        $acr->addPermission('Examples.UserRules.roles');
        $acr->addPermission('Examples.UserRules.roles', 'index');
        $acr->addPermission('Examples.UserRules.roles', 'store');
        $acr->addPermission('Examples.UserRules.roles', 'update');
        $acr->addPermission('Examples.UserRules.roles', 'destroy');
        $acr->addPermission('Examples.UserRules.inherit');
        $acr->addPermission('Examples.UserRules.inherit', 'index');
        $acr->addPermission('Examples.UserRules.inherit', 'store');
        $acr->addPermission('Examples.UserRules.inherit', 'destroy');
        $acr->addPermission('Examples.UserRules.permission');
        $acr->addPermission('Examples.UserRules.permission', 'index');
        $acr->addPermission('Examples.UserRules.permission', 'update');
    }
}

5. And finally, we will add inheritance of permissions from the super administrator to all users.

php artisan make:seeder AddRoleToAllUserSeeder

Source file database\seeders\AddRoleToAllUserSeeder.php:

<?php
namespace Database\Seeders;

use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;
use App\Models\User;

class AddRoleToAllUserSeeder extends Seeder
{
    /**
     * Run the database seeds.
     */
    public function run(): void
    {
        $all = User::all();
        foreach ($all as $one) {$one->inheritPermissionFrom('Role', 'root');}

        // or
        // $acr = new AccessRules;
        // $acr->setOwner('Role', 'root');
        // foreach ($all as $one) {$one->inheritPermissionFrom($acr);}

        // or
        // $mainUser = User::find(1);
        // foreach ($all as $one) {$one->inheritPermissionFrom($mainUser);}
    }
}

Let's now move on to importing all the instructions created in this step:

php artisan db:seed --class=CreateUserSeeder
php artisan db:seed --class=NewsTableSeeder
php artisan db:seed --class=CreateRulesSeeder
php artisan db:seed --class=CreateRootAdminRoleSeeder
php artisan db:seed --class=AddRoleToAllUserSeeder

To perform the same access control and inheritance manipulations discussed above, an alternative method is to use the interface which was added at the beginning of this article. You can access the interface by opening the address "/accessui/" in your project:

List all roles, group and user:

List all rules:

Let's move on to the most interesting part ☕

Various access verification methods and the rules associated with them.
Going forward, the controllers used in the examples will serve as sources of JSON data for the SPA Frontend, thus eliminating the need to create templates.
Anyway, we can always view the outcome of rule verification.

Example 1

In this example, we are using middleware on routing to limit access to the controller.

Apped to file routes\web.php:

Route::get('/example1', [Example1Controller::class, 'index'])->middleware('can:example1.viewAny');

The controller is not utilized in this example
Source to file ...Example1Controller.php:

<?php
namespace App\Http\Controllers\Examples;

use Illuminate\Support\Facades\Response;
use App\Http\Controllers\Controller;
use App\Models\User;

class Example1Controller extends Controller
{
    public function index()
    {
        return Response::json(User::all(), 200);
    }
}

Check what happened:

Example 2

Let's try to check the permission in the action itself
Apped to file routes\web.php:

Route::get('/example2', [Example2Controller::class, 'show']);

Source file ...Example2Controller.php:

<?php
namespace App\Http\Controllers\Examples;

use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Response;
use Illuminate\Support\Facades\Gate;
use App\Http\Controllers\Controller;

class Example2Controller extends Controller
{
    public function show()
    {
        Gate::authorize('example2.view');

        return Response::json(Auth::user()->toArray(), 200);
    }
}

As in an example, you can use all the capabilities of the Laravel Gate facade.

Example 3

This is quite similar to the previous example, but with a separate list of options.
Apped to file routes\web.php:

Route::any('/example3/{frm}', [Example3Controller::class, 'update']);

Source file ...Example3Controller.php:

<?php
namespace App\Http\Controllers\Examples;

use Illuminate\Support\Facades\Auth;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Response;
use Illuminate\Support\Facades\Validator;
use Illuminate\Support\Facades\Gate;
use Illuminate\Support\Facades\Hash;
use App\Http\Controllers\Controller;
use App\Enum\UserProfileFormEnum;

class Example3Controller extends Controller
{
    public function update(UserProfileFormEnum $frm, Request $request)
    {
        // Add the check by indicating after the point of the [Option] field
        Gate::authorize('example3.update.'.$frm->value);

        $user = Auth::user();
        switch ($frm)
        {
            case(UserProfileFormEnum::Name):

                if($request->name) {$user->fill( $request->only(['name']) );}

            break;
            case(UserProfileFormEnum::Password):

                if($request->password) {$user->password = Hash::make($request->password);}

            break;
            case(UserProfileFormEnum::Email):

                $validator = Validator::make($request->all(), [
                    'email' => 'required|email',
                ]);
                if ($validator->fails()) {abort('403', $validator->messages());

                $user->email = $request->email;

            break;
        }

        return Response::json($user->save(), 200);
    }
}

Why does this behavior occur and how does the "Option" differ from the standard rule definition?

It is worth noting that the "Option" field is not linked to the rule, but to the permission itself.
This is done to allow the creation of multiple permissions within a single rule. For instance,
it's possible to retrieve all records by ID that have access without having to create separate tables or fields.

Example 4

In this example, we will utilize the built-in $this->authorizeResource() function which comes with the resource feature. This function is very convenient as it automatically creates checks for each action against the following rules: "viewAny", "view", "create", "update" and "delete".
Apped to file routes\web.php:

Route::apiResource('example4', Example4Controller::class)->parameters([
    'example4' => 'news'
]);

Source file ...Example4Controller.php:

<?php
namespace App\Http\Controllers\Examples;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Response;
use App\Http\Controllers\Controller;
use App\Models\News;

class Example4Controller extends Controller
{
    /**
     * Create the controller instance.
     */
    public function __construct()
    {
        $this->authorizeResource(News::class, 'News');
    }

    /**
     * Display a listing of the resource.
     */
    public function index()
    {
        return Response::json(News::all());
    }

    /**
     * Store a newly created resource in storage.
     */
    public function store(Request $request)
    {
        $news = News::create($request->toArray());

        return Response::json($news->id, 201);
    }

    /**
     * Display the specified resource.
     */
    public function show(News $news)
    {
        return Response::json($news->toArray());
    }

    /**
     * Update the specified resource in storage.
     */
    public function update(Request $request, News $news)
    {
        $news->fill($request->toArray());

        return Response::json($news->save);
    }

    /**
     * Remove the specified resource from storage.
     */
    public function destroy(News $news)
    {
        return Response::json($news->delete());
    }
}

Example 5

In the previous example, we used global rules, which is not very convenient. To overcome this, we can make functionality for creating rules for each controller separately.

To achieve this, we need to modify the main controller, For that we will create trait.
Source file App\Http\Traits\GuardedController.php:

<?php
namespace App\Http\Traits;

use App\Http\Controllers\Controller;

trait GuardedController
{
    /**
     * Map of resource methods to ability names
     * @example ['index' => 'viewAny']
     *
     * @var string[]
     */
    //abstract protected $guardedMethods = [];

    /**
     * Do not automatically scan all available methods.
     *
     * @var bool
     */
    //abstract protected $disableAutoScanGuard = true;

    /**
     * List of resource methods which do not have model parameters.
     * @example ['index']
     *
     * @var string[]
     */
    //abstract protected $methodsWithoutModels = ['index'];

    /**
     * Get the map of resource methods to ability names.
     *
     * @return array
     */
    protected function resourceAbilityMap()
    {
        if (empty($this->disableAutoScanGuard)) {
            $methods = array_diff(
                get_class_methods($this),
                get_class_methods(Controller::class)
            );
            $map = array_combine($methods, $methods);
        } else {
            $map = [];
        }

        $map = array_merge($map, parent::resourceAbilityMap());
        $map = array_merge($map, $this->guardedMethods??[]);

        // Replace name for class App\Http\Controllers\Examples\Example1Controller
        // to guard prefix "Examples.Example1."
        $name = $this->getClassNameGate();

        // Replace standard rule "viewAny" to "Examples.Example1.viewAny"
        foreach ($map as &$item) {$item = $name.$item;}
        unset($item);

        return $map;
    }

    /**
     * Get the list of resource methods which do not have model parameters.
     *
     * @return array
     */
    protected function resourceMethodsWithoutModels()
    {
        $base = parent::resourceMethodsWithoutModels();

        return array_merge($base, $this->methodsWithoutModels??[]);
    }

    /**
     * Get name off class witch namespace for guard
     *
     * @param string|null $action
     * @return string
     */
    protected static function getClassNameGate(?string $action = null): string
    {
        // Replace name for class App\Http\Controllers\Examples\Example1Controller
        // to guard prefix "Examples.Example1."
        $name = str_replace([
            dirname(__TRAIT__, 2).DIRECTORY_SEPARATOR.'Controllers'.DIRECTORY_SEPARATOR,
            DIRECTORY_SEPARATOR,
            'Controller'
        ], [
            '', '.', '.'
        ], static::class);

        return $name.$action;
    }
}

Controller and its example remain exactly the same as in the previous one.
Only added trait (File ...Example5Controller.php) :

<?php
namespace App\Http\Controllers\Examples;
...
use App\Http\Traits\GuardedController;

class Example5Controller extends Controller
{
    use GuardedController;

    public function __construct()
    {
        $this->authorizeResource(News::class, 'News');
    }
...

But the error is already different:

Thus, with minimal modifications to the existing code,
one can easily incorporate dynamic access control capabilities.

Example 6

Here is a fairly simple example that is similar to the second one.
Through a few subtle differences, there is a magical behavior present here.
Apped to file routes\web.php:

Route::any('/example6/{news}', [Example6Controller::class, 'update']);

Source file ...Example6Controller.php:

<?php
namespace App\Http\Controllers\Examples;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Response;
use Illuminate\Support\Facades\Gate;
use App\Http\Controllers\Controller;
use App\Models\News;

class Example6Controller extends Controller
{
    public function update(Request $request, News $news)
    {
        Gate::authorize('example6.update', $news);

        $news->fill($request->toArray());

        return Response::json($news->save?1:0);
    }
}

Let's take a closer look at this. If we have rule "example6.update.self", we need to specify to the system to check rule "example6.update" and added ".self" pass the record object to be checked under the hood of ACR.

ACR work will look like this:

if (
    Gate::allows('example6.update.self')
    && $user->id === $news->user_id
) {
    return true;
}

Additionally, it's worth noting that if we are not checking the user but another entity, such as a moderator, *ACR * keeps track of it, and the check will look like this under the hood:

$moderator = App\Models\Moderator::find('...');
if (
    Gate::forUser($moderator)->allows('example6.update.self')
    && $moderator->uuid === $news->moderator_uuid
) {
    return true;
}

There is no need to perform such checks anymore, as the magic method will handle them automatically.

Example 7

Although this is not ABAC, the necessary attribute-based access control functionality can be achieved by adding the use of Laravel's built-in policy mechanism.

All the previous examples focused on checking access to the controller, but we can use the same approach in "Policy" to implement access control for attributes with all their variations.
For this, it is necessary to generate a policy for our model:

php artisan make:policy NewsPolicy –model=News

Source file ...NewsPolicy.php:

<?php
namespace App\Policies;

use App\Models\News;
use App\Models\User;
use Illuminate\Auth\Access\Response;

class NewsPolicy
{
    public function availableUpdateOnSomeTime(User $user, News $news): ?bool
    {
        if(
            $user->can('Example7News.allowedEditLast24Hours', $news)
            && stripos($user->name, 'author') !== false
            && ($news->created_at->isToday() || $news->created_at->isYesterday())
        ) {
            return true;
        }
        return null;
    }
}

After that, it will be necessary to update in the AuthServiceProvider class $policies, as written below:

protected $policies = [
    News::class => NewsPolicy::class,
];

Now check policy in the controller:
Source file ...Example7Controller.php:

<?php
namespace App\Http\Controllers\Examples;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Response;
use App\Http\Controllers\Controller;
use App\Models\News;

class Example7Controller extends Controller
{

    public function index(News $news)
    {
        $this->authorize('availableUpdateOnSomeTime', $news);

        return Response::json($news->toArray());
    }
}

Therefore, we now have the capability to check not only the rules individually, but also to verify the attributes of the model.

It is important - if you add rule "availableUpdateOnSomeTime" and permission to user, then the policy will not be checked.

Final example ⚡

In its default state, the AccessUi interface does not include any checks regarding the level of access granted.
To address this, we can create a proxy controller in this example that will verify all the permissions before any data manipulation is done.
First, turn off the standard AccessUi routes,
File config/accessUi.php:

    /**
     * Panel Register
     *
     * This manages if routes used for the admin panel should be registered.
     * Turn this value to false if you don't want to use admin panel
     */
    'register' => false,

Then, we will create 2 controllers: "UserRulesController" and "UserProfileController", which uses Trait "RunsAnotherController" to run the other AccessUi controllers.
The implementation itself is view in files "user-rules.blade.php" and "user-profile.blade.php".
The files may be a bit lengthy, but they can be viewed separately in the repository.

As a result, we will have individual pages in our style with access rights verification:

Authorized user profile page:

Rules list and only roles (hidden user on owner page) list:

In conclusion, implementing "wnikk/laravel-access-rules" (ACR, ACL, RBAC) using in Laravel is a powerful way to ensure that users are granted access to only the resources they are authorized to use. With the help of Laravel's built-in middleware and authorization features, it is possible to easily create and manage complex access control policies at both the global and controller-specific levels. By using Access-Control-Rules, developers can add dynamic access control capabilities to their Laravel applications with minimal code changes, while ensuring that the application remains secure and easy to maintain.