Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

vidhyaprakash85's avatar

laravel custom guard timeout redirect to guard login page

I have two guards in my application

<?php

return [
    'defaults' => [
        'guard' => 'web',
        'passwords' => 'users',
    ],
    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],
        'student' => [
            'driver' => 'session',
            'provider' => 'student',
        ],
    ],
    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => App\Models\User::class,
        ],

        'student' => [
            'driver' => 'eloquent',
            'model' => App\Models\Student::class,
        ],
    ],

    'passwords' => [
        'users' => [
            'provider' => 'users',
            'table' => 'password_resets',
            'expire' => 60,
            'throttle' => 60,
        ],
    ],
    'password_timeout' => 10800,
];

When i login with student guard and if timeout happens it redirect to default login not the student/login.

How to customize and tuts

0 likes
4 replies
tisuchi's avatar

@vidhyaprakash85 May be you can use custom middleware for your student login.

public function handle($request, Closure $next, $guard = null)
    {
        if (Auth::guard($guard)->guest()) {
            if ($request->ajax() || $request->wantsJson()) {
                return response('Unauthorized.', 401);
            } else {
                if ($guard === 'student') {
                    return redirect()->guest(route('student.login'));
                }
                return redirect()->guest(route('login'));
            }
        }

        return $next($request);
    }

Don't forget to register your middleware in the app/Http/Kernel.php.

Then use this middleware in your route:

For example:

Route::middleware(['auth:student'])...
pkboom's avatar

Putting students in users table and add is_student in users table is not a bad idea. Can save a lot of additional work based on contexts.

jlrdw's avatar

Also a user is a user. As has been discussed here many times:

  • Authentication is a logged in user
  • Authorization determines what a logged in user can or cannot do.

An example I have used:

  • 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 user 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.

Only suggestions

Snapey's avatar

When the session expires and the user turns up with a new request, how can you possibly know what type of user they are and where to redirect to?

Remember, nothing happens on the server on its own. Its always in response to a client request.

What you want to do is not possible.

Please or to participate in this conversation.