Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

amir5's avatar
Level 7

How do you manage permissions

Think of a admin dashboard with users with different roles & permissions, How those permissions should be managed?

One way is creating permissions in seeder and run seeder in every deploy to store newly added permissions, but you should check on every route for permissions.

The other way is using route names(actions) as permission names, and a command that auto generates them, then you don't need to check permission on every route, one global middleware is enough. But how things like a user can see posts.index but should see their own posts only, but other user can see all of them, is possible?

0 likes
4 replies
jlrdw's avatar
  • Aurhentication = logged in
  • Authorization = what the logged in user can or cannot do.

But how things like a user can see posts.index but should see their own posts only, but other user can see all of them, is possible?

It's written in the query, some if constructs.

  • Bob is an admin

  • Suzy is admin and does bookkeeping

  • Mary is a bookkeeper only

  • If Bob is logged in, Bob can only do admin stuff and all access to user stuff. But Bob cannot mess with bookkeeping.

  • If Suzy is logged in she can access admin stuff and bookkeeping and accounting stuff.

  • If Mary is logged in she cannot mess with admin stuff, but has access to bookkeeping and accounting stuff.

So I just check at method level if the logged in users role can or cannot access that method / function.

And use query scopes to let a user edit / view their own data or an admin can access all users data.

Each app will be different as to who can do what. .

So in pseudocode:

public function makeInvoice()
    {
        if (a required role of bkeep is not true here) {   // bkeep = bookkeeper
            return redirect('somewhere'); // whereever you redirect to if not authorized
        }
        // Rest of method here is accomplished if 
        // the logged in user has the required role of 'bkeep'.
    }

Again just examples.

Also a Spatie example I saw:

public function update(Request $request, Post $post) {
    if ($post->author !== auth()->user()->id || auth()->user()->cannot('edit posts'))
        abort(404);// or redirect, or whatever action 
    }
    //rest of method if all okay
}

In summary RBAC is at least 3 main steps:

  • A login required
  • An authorization implementation to determine what the logged in person with role can or cannot do
  • Protection of URL and parameters, checking that the logged in users id matches the id used in a query

Each application will require unique tweaks in RBAC, no two apps are exactly the same.

    public function getPets($query, $petsearch = '')
    {
        $petsearch = $petsearch . "%";
        $query->where('petname', 'like', $petsearch);
        if (ChkAuth::userRole('admin') === false) {    // ChkAuth is my custom code
            $userid = Auth::user()->id;
            $query->where('ownerid', '=', $userid);
        }
        $results = $query->orderBy('petname', 'asc')->paginate(5);
        return $results;
    }

An admin can see all.

Proper security is and should be a steep learning curve.

Edit:

A lot of laravel users us spatie for permissions, check it out. I use laravel authentication but my own RBAC. I don't suggest doing it yourself unless experienced.

See the learn laravel in 30 days course also, he covers the basics of this topic.

1 like
amir5's avatar
Level 7

@jlrdw I have already implemented role/permissions. I have a command that syncs route names as permission names in database. And I was thinking of how can I check user can see all posts or not, because the problem is I'm checking based on route and I have only one permission for that route. Maybe I can manually add permission like posts.any in database seeder, but I wanted to see what are other options If using permission based on route/action.

Snapey's avatar

Roles should give a collection of permissions to a user.

Permissions should be embedded in your code to decide what users can do (and by lack of permission, what they cannot do).

A model policy is the bit you are missing. A policy decides what records the permission applies to. So permission says you can edit a model, but policy says what models you can interact with.

For instance, a business manager might be able to approve employee holidays, but they can only approve holidays for their own team members. As you can see the policy is very much attached to the business requirements so its not possible to give specific code.

1 like

Please or to participate in this conversation.