jalaf11201's avatar

Is it okay to have several Blade views, Routes and Controllers for the same thing for different Authority?

I have 5 types of authority:

super admin (highest), dynamic roles created by super admin, community owner, dynamic roles created by community owner, normal users,

I have separate community controller, blade views and routes for super admin and user. And I might do one more for dynamic roles. I will check the authentication from the routes with middleware. Is it okay to do these?

Users can have different roles. And if they delete their things as a user it will get soft delete, while as other role it will get status = deleted. So I have to know, as what role they are requesting this action.

When user goes to their roles page and go to a specific role panel, I will put the hidden roleId on forms, so I can check in authorization, if this user have this role, and if this role has the permission needed for the action. How is it? Is it a bad practice?

I would appreciate your guidance, this is my first time working with auth systems, so I don't know what I do might be bad practice. The project is final course project.

1 like
5 replies
JussiMannisto's avatar

When user goes to their roles page and go to a specific role panel, I will put the hidden roleId on forms, so I can check in authorization, if this user have this role, and if this role has the permission needed for the action. How is it? Is it a bad practice?

Don't do this. Anyone could modify the hidden input in the page source and spoof a different role.

You don't need to add any hidden inputs. Your backend already knows who the user is, and you can use Laravel's built-in authorization features. I strongly recommend you read the documentation first:

https://laravel.com/docs/13.x/authorization

But I can give you a quick rundown.

Below is a simple policy class for a Post model. It has just one authorization check: can a user edit a post. Editing is allowed if the user is a super-admin or the original author of the post.

class PostPolicy {
    public function edit(User $user, Post $post): bool {
        if ($user->role === 'super-admin')
			return true;
		 
		return $user->id === $post->user_id;
    }
}

Here's how you register the policy on the model:

use Illuminate\Database\Eloquent\Attributes\UsePolicy;

#[UsePolicy(PostPolicy::class)]
class Post extends Model {
    ...
}

Once you have the policy registered, you can do authorization checks in code, middleware, and Blade templates. Some examples:

// Authorization check in middleware:
Route::patch('/posts/{post}', [PostController::class, 'update'])
	->can('edit', 'post')
	->name('posts.update');
	
// Authorization check in a controller:
if ($request->user()->can('edit', $post)) {
	...
}

// Authorization check in Blade:
@can('update', $post)
	...
@endcan

The docs have all the details.

3 likes
vincent15000's avatar

My opinion :

  • it depends on what you need, but it's not a bad pratice to have one controller for the superadmin and one controller for the users

  • the same logic can be applied to views and routes

  • to check if a user has the permission to do an action, it's not a good practice at all to only check the role id in the frontend, you have to check authorizations in the backend and the best way to do that is to write policies, inside policies you can check the roles and/or the permissions

What you name authority is a role.

In pratice a user can have one or several roles and each roles comes with some permissions. It's generally not recommended to assign permissions directly to users. The best way is to assign permissions to roles and to assign roles to users. But for fine permissions control, you can occasionally assign permissions to users if it's really needed in your application, I don't do so, but sure some cases can justify to do so.

If you need help to do all this, you can have a look at this Laracasts series.

https://laracasts.com/series/mastering-permissions-in-laravel

2 likes
jlrdw's avatar

When user goes to their roles page and go to a specific role panel, I will put the hidden roleId on forms, so I can check in authorization, if this user have this role, and if this role has the permission needed for the action. How is it? Is it a bad practice?

I agree with @jussimannisto do not use hidden fields. I suggest view some video series here on authentication and authorization. And review the documentation.

These checks are best done server side.

I also suggest taking this training: https://laracasts.com/series/laravel-from-scratch-2026

Also I gave an idea here: https://laracasts.com/discuss/channels/general-discussion/how-should-i-structure-authorization-for-owner-super-admin-community-admin-and-dynamic-roles-in-a-laravel-social-network?page=1&replyId=975679

Having same controller but a separate method for user verses admin.

2 likes
jalaf11201's avatar

Thank you for the review, I appreciate it.

Initially I was only checking if the user had any role with the required permission in the PermissionService. Then I also wanted to identify which role the user is acting as, since it might change some actions, like different delete types or maybe save it in logs in the future. So that's why I though maybe I should also send the roleId from UI.

I'll look at the docs and links you shared to understand this better. I didn't use Policies before too, only did authorization in services, and used middleware for authentication. Thanks again!

1 like
vincent15000's avatar

Policies is great to keep all authorizations at the same place.

A service is to handle business logic, you shouldn't write any authorization code in a service.

For example, in my code :

  • the services only execute the code for the business logic : get, store, update, delete, ...

  • the policies contain the authorizations

  • the controllers check for authorizations via the policies and then execute an action via the services

2 likes

Please or to participate in this conversation.