@connor1231 Wow, I didn't know that. Even if it's not big, these little details make it so cool!

One thing to add here the :attribute value in messages() has some hidden functionality. If you want the attribute name to have a capital letter use :Attribute if you want it to be full caps lock use :ATTRIBUTE. Really cool stuff...

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

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!

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.

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

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.

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.

Don't get hung up on the terms. A "Super Admin" means nothing to me except:

They can or cannot do something.

Think like this:

• Authentication = Logged in
• Authorization = What they can or cannot do with their role /s

I have an app where the admin can view but not otherwise mess with bookkeeping.

Learn about query scopes also, that way in a query a user can edit only their data but an admin can view all and edit certain fields.

DO NOT let AI write Authentication and Authorization, do this yourself. Go through the (yes steep) learning curve on this stuff. It gets easier once learned.

In a large app I do use separate controller methods, like:

• index is general user
• indexAdmin for admins of course

And separate views. In a smaller app I might not have the separation. This is highly subjective.

Note that the documentation covers this well and there are entire videos on this right here on laracasts.

Hi, I'm creating a basic Laravel social network as my final project and I'm stuck on the authorization structure.

My systems authority levels:

super admin (static role, highest authority, have separate panel) community admin (a user who created a community) normal user dynamic global roles (created by super admin) dynamic community roles created by community admins

First I am wondering how I should separate the controllers for the same actions (like community controllers, post controllers). I want different behavior on who deleted the post, community, etc. If the user deleted their own things it is soft deleted, while if super admin or others deletes , it gets status delete, only the user will be seeing it as deleted.

The difficult part is the same person can have multiple authorities at once, they can be owner of the post, and also the community admin or another role in that community So when they delete a post, I need the system to know which context they are acting. So I can't just check it with one haveAuthority function.

I'm also unsure on how to separate controllers or environments (blades). I have separate controllers for super admin since they have different panel. Things got a bit complicated and I don't know how I should handle different levels of authority.

So my main questions are:

**How should I structure controllers for different authority levels in Laravel?

**How should I design one authority check system that can handle owner, super admin, community admin, and dynamic roles or I shouldn't?

**What is the best way to determine the acting context when one user can have multiple roles at the same time?

**Where can I learn more about this kind of authorization / authority architecture?

I searched and couldn't find what I need. I'd really appreciate guidance on architecture or the system. That's the part I'm struggling the most.

Mainly I have the super admin (static role), community admin (static role), just a user, and dynamic roles, created by super admin (global roles) or community admin (community roles).