26 - Permissions, Roles, Gates: Back-End

Finally, in this course, we will take care of permission. In this lesson, we will take care of the back-end part. We will create Role and Permission models. Then we will add two roles: admin and editor. The admin role will be able to do everything and the editor will not be able to delete the posts.

network tab

First, we will create the models with migrations for roles and permissions.

php artisan make:model Role -m
php artisan make:model Permission -m

database/migrations/xxxx_create_roles_table.php:

public function up(): void
{
    Schema::create('roles', function (Blueprint $table) {
        $table->id();
        $table->string('name');
        $table->timestamps();
    });
}

app/Models/Role.php:

class Role extends Model
{
    protected $fillable = ['name'];
}

database/migrations/xxxx_create_permissions_table.php:

public function up(): void
{
    Schema::create('permissions', function (Blueprint $table) {
        $table->id();
        $table->string('name');
        $table->timestamps();
    });
}

app/Models/Permission.php:

class permissions extends Model
{
    protected $fillable = ['name'];
}

Next, we need to create a pivot table for...

The Full Lesson is Only for Premium Members

Want to access all of our courses? (36 h 00 min)

You also get:

61 courses

Premium tutorials

Access to repositories

Private Discord

Get Premium for $129/year or $29/month

Already a member? Login here

Luis Antonio Parrado 2 years ago

According to this tutorial we are defining the Gates but we are not using them in the controllers (or routes) to allow/prohibit the actions.

👍 2

Luis Antonio Parrado 2 years ago

My solution in app/Http/Controllers/Api/PostController.php:

// ...
 
public function store(StorePostRequest $request)
{
    $this->authorize('posts.create');
 
    // ...
}
 
//...
 
public function update(Post $post, StorePostRequest $request)
{
    $this->authorize('posts.update');
 
    // ...
}
 
public function destroy(Post $post)
{
    $this->authorize('posts.delete');
 
    // ...
}
 
// ...

javi 2 years ago

You are right. Database tables permissions, permission_role and role_user are correctly populated. But without these lines all users can delete posts.

Luis Antonio Parrado 2 years ago

foreach Closing bracket } is missing in app/Providers/AuthServiceProvider.php into boot method.

public function boot(): void
    {
        try {
            foreach (Permission::pluck('name') as $permission) {
                Gate::define($permission, function ($user) use ($permission) {
                    return $user->roles()->whereHas('permissions', function (Builder $q) use ($permission) {
                        $q->where('name', $permission);
                    })->exists();
                });
            } // **MISSING**
        } catch (QueryException $e) {
            //
        }
    }

Dmytro Sakharuk 2 years ago

As a respected ambassador of programming principles in general and KISS/YAGNI in particular, I must say that this is too complicated for this limited functionality :)

I would limit myself to the role column in the users table. Casting it to App\Enums\Role

namespace App\Enums;
 
enum Role: int
{
    case ADMINISTRATOR = 1;
    case EDITOR = 2;
}

And the policy App\Policies\PostPolicy

class PostPolicy
{
    // ...
    public function delete(User $user, Post $post): bool
    {
            return $user->role === Role::ADMINISTRATOR;
    }
    // ...
}

Modestas 2 years ago

But that is a completely different approach from our example.

In your code, you are simply saying that user can have only one role, while in our example - we allow multiple roles. Then we are looking at your "KISS/YAGNI" example of a policy and it's hard-coded per role. What if our user has role Admin, but they are just learning and should not have ability to delete the user? I can't handle that case with your example.

Or to shorten what I just said - there are millions of ways to build the same thing. It just boils down to the project needs and future expansions

Dmytro Sakharuk 2 years ago

So, it all boils down to necessity. In this case, the functionality is excessive for CRUD operations for individual roles. The pinciples and approaches to software development advocate for keeping code simple and avoiding unnecessary functionality that is redundant.

Modestas 2 years ago

In a way, you are right. This indeed goes deeper than it should. But one thing we learned over the years of building roles/permissions systems - they change rapidly. And preparing a system like this (or just installing spatie permissions package) is a great way to have the basics covered :) It is not that complex to understand and work with, yet provides you with a good base for future changes.

Permissions, Roles, Gates: Back-End

The Full Lesson is Only for Premium Members

We'd Love Your Feedback

Thank You!