Laravel with multiple role user : is my database design ok ?

@saedyousef That's effectively interesting ... I didn't thought about the fact that you don't have to check the role given you handle the permissions.

For the moment I only need to assign permissions to the roles and not to the users. So each user is allowed to do something according to his role.

Is your allowed() method similar to the policy authorization $this->authorize() ? Or do you use the alllowed() method inside the policies ?

What you suggest me would be to have this configuration ?

members: id, company_id, user_id, roles

@vincent15000 This is the package we use Permit

@saedyousef I think that the Laravel policies can do the same.

@vincent15000 Is the members your users table?

@saedyousef No, the members table is to attach some users to a company. Each user can possibly work for several companies, but not necessarily with the same roles.

You have the details at the beginning of the post.

@vincent15000 Ah now I see. I think the group of permissions approach would be more useful. In your approach, if you decided to change permissions for users with role accountant, you need to update all the permissions of the users one by one, which is not handy. If you take the groups approach, you will have extra tables yes, but you will not get to this situation.

@saedyousef For the moment, I don't need to manage the permissions from the frontend, all permissions are definitively declared inside the code. What do you suggest me according to the informations I gave at the top of the post ?

@saedyousef Ok so you don't filter the requests via a middleware but directly in the controller.

@vincent15000 I look at it like:

• 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.

Another 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.

@jlrdw Ok thank you very much. That's very clear now. I never really had RBAC steps in mind, but effectively it's the basis. Thank you ;).