The only way to update the content of a page without refreshing the page is to use AJAX request, so you have to use JavaScript, send the requests from JS (for example with axios or the native JS function fetch) and update manually the DOM.

You can do this an easier way using either AlpineJS, or HTMX, or Turbo, or simply why not Livewire.

https://alpinejs.dev/

https://laravel.com/docs/13.x/blade#rendering-blade-fragments

https://laracasts.com/series/crafting-web-applications-with-htmx

https://htmx.fr/

https://turbo.hotwired.dev/

https://livewire.laravel.com/

If you want to keep your code light, I suggest you rather AlpineJS or HTMX or Turbo.

I'm creating a community based SN, I created manage section for community owners, and there is nav on top like general, privacy, sections (flairs), users (follow, requests), posts (requests, pinned, etc.) inside. I created blade pages for them, but inside them there are sections again. Like Followed, Requests, Pinned, Removed etc. Making separate pages for them would be bad. I don't know if I should just send arguments ?filter=request and display it based on that. What would be professional way for this type of sub sections (navs)?

Also after creating some things I just realized that I have to make sure the page is not getting refresh with the actions like follow, pin, remove, reject, accept etc. There are tons of them, I did follow, delete with the async fetching with js. And also realized I have to fetch posts with it too because of pagination. I don't want it to refresh for next other 20 posts every time. I'm wondering if it would be ok to use tons of async fetch and dom manipulation in the page.

I'm doing this with laravel and without front frameworks. I am having trouble on how to do the architecture so it won't bite me back. I would appreciate your suggestion and examples on these things.

Edit: also, which is the better way, using toggle on action like ban/unban, like/dislike, follow/un, pin/unpin, or creating separate routes and functions for them?

Just use #[CurrentUser] attribute as dependency injection, it will automatically resolve current authenticated user. For example

use App\Models\User;
use Illuminate\Container\Attributes\CurrentUser;

public function profile(#[CurrentUser] User $user)
{
    return view('pages.profile.index', [
        'user' => $user
    ]);
}

If its to show another user using route model binding, then just type hinting the User class

use App\Http\Controllers\UserController;
use App\Models\User;

// Route definition...
Route::get('/users/{user}', [UserController::class, 'show']);

// Controller method definition...
public function show(User $user)
{
    return view('user.profile', ['user' => $user]);
}

Lastly, I recommend watching https://laracasts.com/series/laravel-from-scratch-2026

Hi, I'm having a hard time to handle little pages. And I have to take user data in all the pages. I will take different data in other pages just like in communities. And also should I put everything community related to community service and use it in community controllers and profile community pages or etc? or Can I just do it like this.

Where can I see some examples for this cases? I always did basic crud, so don't know how to handle this cases.

public function show(Request $request) { $user = User::where('username', $request['username'])->firstOrFail();

    return view('pages.profile.index', [
        'user' => $user
    ]);
}

public function comments(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    return view('pages.profile.comments', [
        'user' => $user
    ]);
}

public function communities(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    $communities = Community::query()
        ->where('owner_user_id', $user->id)
        ->when(auth()->id() !== $user->id, function ($query) {
            $query->where('visibility', 'public')
                ->where('status', 'active');
        })->get();

    return view('pages.profile.communities', [
        'user' => $user,
        'communities' => $communities
    ]);
}
public function about(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    return view('pages.profile.about', [
        'user' => $user
    ]);
}

public function saved(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    if($user->id !== auth()->user()->id) {
        return back()->with($this->errorMessage('Anauthorized to access.'));
    }

    return view('pages.profile.saved', [
        'user' => $user
    ]);
}

public function hidden(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    if($user->id !== auth()->user()->id) {
        return back()->with($this->errorMessage('Anauthorized to access.'));
    }

    return view('pages.profile.hidden', [
        'user' => $user
    ]);
}

public function history(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    if($user->id !== auth()->user()->id) {
        return back()->with($this->errorMessage('Anauthorized to access.'));
    }

    return view('pages.profile.history', [
        'user' => $user
    ]);
}

public function reacted(Request $request) {
    $user = User::where('username', $request['username'])->firstOrFail();

    if($user->id !== auth()->user()->id) {
        return back()->with($this->errorMessage('Anauthorized to access.'));
    }

    return view('pages.profile.reacted', [
        'user' => $user
    ]);
}

@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).