Laravel: How to Check Custom Middleware Status in Blade Templates

As a senior developer working with the Laravel ecosystem, I frequently encounter situations where we define custom logic within middleware, but struggle to expose that state directly within our Blade templates. The scenario you've presented—trying to use @if (Auth::isTeacher()) after defining a custom middleware—is a very common hurdle. It highlights the difference between how Laravel handles standard authentication checks and how custom application-level permissions should be managed.

This post will walk you through why your initial attempt failed and, more importantly, show you the correct, idiomatic Laravel way to handle capabilities and permissions so you can build robust applications.

The Pitfall: Middleware vs. Blade Logic

You correctly set up your middleware to check a condition and redirect if the user fails the test:

// Example of your middleware logic
if($user && $user->capability == 3) {
    return $next($request);
} else {
    return redirect('/login');
}

When you call Auth::isTeacher(), Laravel checks if a method named isTeacher() exists on the Illuminate\Auth\AuthManager or if it's defined as a global helper. Since you only implemented the logic inside your middleware handler, there is no globally accessible method for Auth to check yet. The middleware successfully performed an authorization step (redirecting), but it did not set a state flag that the view layer could easily read.

The core issue is that custom checks defined in middleware are typically designed for access control (blocking access) rather than presentation logic (displaying conditional content).

The Laravel Way: Using Gates and Policies for Permissions

In modern Laravel development, relying on manually checking flags set within the request lifecycle for display logic is an anti-pattern. The best practice for handling permissions and capabilities in Laravel involves using Gates and Policies. These features are deeply integrated into the Eloquent ORM structure, making your code cleaner, more testable, and easier to manage across your application, aligning perfectly with the philosophy of well-structured code promoted by resources like Laravel Company.

Step 1: Define a Gate

A Gate is essentially a named authorization check. We define it in AuthServiceProvider and link it to a class method that determines if the user has permission.

In app/Providers/AuthServiceProvider.php:

use Illuminate\Support\Facades\Gate;
use App\Models\User;

public function boot()
{
    $this->registerPolicies();

    // Define the 'teacher' gate
    Gate::define('is_teacher', function (User $user) {
        // Check the capability directly on the user model
        return $user->capability == 3;
    });
}

Step 2: Use Gates in Your Blade Template

Once you have defined a Gate, Laravel makes it available via the Gate facade or by using the helper function can(). This is how you check permissions directly in your views.

Instead of trying to call an ambiguous Auth::isTeacher(), you use the explicit gate check:

{{-- Check if the currently authenticated user has the 'is_teacher' permission --}}
@if (Gate::allows('is_teacher'))
    <h1>Welcome, Teacher!</h1>
    <p>You have access to teacher resources.</p>
@else
    <p>Access denied. Please log in as a teacher to view this content.</p>
@endif

Alternatively, if you are inside a controller or middleware and need to check permission before proceeding, you use the Gate facade:

// In your Controller method:
public function showTeacherDashboard()
{
    if (Gate::allows('is_teacher')) {
        return view('dashboard');
    }
    abort(403, 'Unauthorized action.');
}

Conclusion

While creating custom middleware is essential for controlling where a user can go (authorization), using Laravel's built-in Gates and Policies is the correct approach for determining what a logged-in user is allowed to see or do (permission). By shifting your logic from custom middleware checks into the Gate system, you create a more scalable, maintainable application that adheres to best practices. Always strive to use the tools provided by the framework—they are designed to work together seamlessly!