You need authorization and scopes to determine who can and cannot do certain things.
From a previous answer I gave:
-
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 used 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.
You also have to ensure someone doesn't change an id in the url by matching the authenticated user id is the one in the query.