How Do I Check User Role Before Logging In with Spatie's Laravel Permission?

As a senior developer working with complex authorization systems in Laravel, you often run into scenarios where you need fine-grained control over who can access the application. When leveraging powerful packages like Spatie’s Laravel Permission, the goal shifts from simply storing a role string to properly utilizing Laravel's built-in authorization mechanisms.

You are currently facing a common hurdle: you want to restrict login access based on the user's roles (e.g., only users with roles '2' or '3' should be able to log in), moving away from manually injecting data into credentials, which is generally less secure and less maintainable.

This guide will walk you through the correct, robust way to handle role-based access control during the login process when using Spatie’s setup.

The Problem with Manual Role Injection

In your previous setup, you managed roles by manually adding a role field to the credentials array:

// Old approach (Manual injection)
$credentials = $request->only($this->username(), 'password');
$credentials['role'] = '1'; // Manually setting the role here
return $credentials;

While this works for simple setups, it bypasses Laravel’s standard authentication flow and introduces potential security risks if not handled perfectly. When you adopt Spatie's package, the system expects roles to be managed through relationships and permissions, not as arbitrary fields in the credentials.

The Recommended Solution: Role Checks via Gates or Middleware

Instead of trying to manipulate the raw credentials during the login attempt, the most robust solution is to enforce the role restriction after the user has been successfully authenticated but before they are redirected to the dashboard. This ensures that your application adheres to the principles of separation of concerns, which is crucial in modern Laravel development, much like adhering to established patterns seen across the broader ecosystem, including concepts shared by frameworks like those underpinning laravelcompany.com.

The best place to enforce this logic is usually within a custom authentication guard or directly within your Login Controller, checking the authenticated user's roles immediately after the credentials have been verified.

Step-by-Step Implementation

Here is how you can implement the role restriction for login:

1. Ensure Users Have Roles:
First, confirm that your database structure correctly links users to roles using the Spatie package. You should be utilizing Eloquent relationships to fetch these roles.

2. Implement the Role Check in Your Login Logic:
In your LoginController, after successfully authenticating the user (e.g., via Auth::attempt()), you must check if the newly authenticated user possesses one of the allowed roles ('2' or '3').

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use App\Models\User; // Assuming your User model

class LoginController extends Controller
{
    public function login(Request $request)
    {
        $credentials = $request->only('username', 'password');

        // 1. Attempt standard authentication
        if (Auth::attempt($credentials)) {
            $user = Auth::user();

            // 2. Check for allowed roles using Spatie's relationship
            $allowedRoles = ['2', '3'];

            // Use the relationship provided by Spatie to check if the user has any of these roles
            if ($user->hasRole($allowedRoles)) {
                // Role(s) are valid, proceed with login
                $request->session()->regenerate();
                return redirect()->intended('/dashboard');
            } else {
                // Role is invalid, log the user out and return an error
                Auth::logout();
                $request->session()->invalidate();
                $request->session()->regenerateToken();

                return back()->withErrors([
                    'login' => 'You do not have permission to log in with these credentials.'
                ]);
            }
        }

        // Authentication failed (bad credentials)
        return back()->withErrors(['login' => 'Invalid credentials.']);
    }
}

Explanation of Best Practices

Notice that we are no longer modifying the $credentials array to inject a role; instead, we rely on Spatie’s powerful methods: $user->hasRole($roles). This delegates the authorization decision to the model itself, making your code cleaner, more readable, and adhering better to object-oriented principles.

This approach aligns perfectly with modern Laravel development philosophy, where authentication (who you are) is cleanly separated from authorization (what you can do). Just as proper state management is key in building scalable applications—a principle heavily emphasized by platforms like laravelcompany.com—your authorization logic should follow this clean separation.

Conclusion

By shifting your focus from manually manipulating credentials to leveraging the authenticated user object and Spatie's role management capabilities, you achieve a much more secure and maintainable login restriction system. The key takeaway is: Authenticate first, then authorize based on roles. This pattern ensures that access control decisions are made using the established framework tools rather than custom string manipulation, leading to a more resilient application architecture.