LaravelKid's avatar

Acces to Adminpanel via permission "can_access_adminpanel" or role "admin"? Whats better?

I am unsure if I should create permissions to access the admin panel and attach the permission to the role admin. Then always check for the permission or just check for the role and no need to create a permission for that?

0 likes
3 replies
jlrdw's avatar
jlrdw
Best Answer
Level 75

Generally there are several ways to deal with roles, permissions, etc.

I just have a role field added to the user table, but it can contain multiple roles.

For example:


   roles 
-------------
admin
bkeep  // for bookkeeper
admin,bkeep   // both roles
user

I check if a role is matched via an array:

    
        $role = $user->role;
        $checkrole = explode(',', $role);
        if (in_array('admin', $checkrole)) {
            // do whatever
        } else {
           // whatever else
        }
   

That's just for an admin, other roles I handle a little different.

I work with the roles and verify a role matches a controller.

For example in the accounts controller for one method I have:

public function accounts()
    {
         Cln::chklog('bkeep');
         // more

Rather than having all kinds of can, cannot, etc, I wrote a class that handles laravel Auth in the background.

It checks like above if bkeep is one of the roles of the logged in user. If so no problem, if not, access is not granted. I just like handling it on each controller like that.

Acces to Adminpanel via permission "can_access_adminpanel" or role "admin"

In your case, and if a very secure app, you could do both.

Permissions is more for can an admin for example edit things in bookkeeping.

Usually no, they can view. That's where queries come in.

Queries that allows a bookkeeper to completely add, edit, etc. But a query is needed for admin to view the data only.

Some people write one view, with if - else -can -cannot - etc Meaning for bookkeeper you have your edit links. For admin no edit links.

But, and this is just me, by time you have all those if - else -can -cannot - etc which can become a mess, I pefer to have a separate controller methods and separate views for bookkeeper and admin.

So I check roles, and let permissions take care of themselves in the query.

  • admin can view and edit any post
  • user can only view and edit their post

So a query without the where user_id for admin

a query with the where user_id for user.

This has to be done anyway, so by checking role, permissions can be or don't have to be used.

It depends on how well you work with the roles, and if you don't mind can, cannot, and a bunch more if - else all over. You may not mind.

Also you still need to check in case of post, if the current logged in user owns a post:

$post = Post::find($id);
if ($post->user_id === Auth::user()->id {
  // allow edit
}

is a way to prevent a user from editing another user post.

If the system is meant for that behavior, a user can edit their own post, permissions are then redundant.

The system itself is designed for that. Permission is there already, the check is to ensure it's the correct logged in user.

jlrdw's avatar

@LaravelKid Remember, that was just the way I like doing it. Still learn laravel's authorization and practice it.

Even Jeffrey in a video mentions there are several flexible ways to implement. So if you are new to it, practice the different ways and do what you feel is the best for your app.

I just like checking at controller level.

siangboon's avatar

a role come with the permissions will make more sense and it allow more and flexible access control, if not i'll usually called user group/type. Anyway it's up to personal and the project need.

Please or to participate in this conversation.