Why middleware filters requests in Laravel

Introduction

Middleware acts like a gatekeeper that checks requests before they reach your app. It helps keep your app safe and organized by filtering requests.

To check if a user is logged in before showing a page.

To block bad or harmful requests from reaching your app.

To add extra information to requests, like language or location.

To log or track requests for monitoring.

To redirect users based on certain rules, like age or role.

Syntax

Laravel

<?php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class CheckSomething
{
    public function handle(Request $request, Closure $next)
    {
        // Check or modify the request here
        if (/* some condition */) {
            return redirect('somewhere');
        }

        return $next($request);
    }
}

Middleware classes have a handle method that gets the request and a next function.

You must call $next($request) to let the request continue to the app.

Examples

This example checks if the user is logged in. If not, it sends them to the login page.

Laravel

<?php
public function handle(Request $request, Closure $next)
{
    if (!$request->user()) {
        return redirect('login');
    }
    return $next($request);
}

This example blocks requests that have a specific header, stopping them with a 403 error.

Laravel

<?php
public function handle(Request $request, Closure $next)
{
    if ($request->header('X-Blocked')) {
        abort(403, 'Access denied');
    }
    return $next($request);
}

Sample Program

This middleware checks if the user is under 18 years old. If yes, it redirects them to a 'no-access' page. Otherwise, it lets the request continue.

Laravel

<?php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class CheckAge
{
    public function handle(Request $request, Closure $next)
    {
        if ($request->input('age') < 18) {
            return redirect('no-access');
        }
        return $next($request);
    }
}

Important Notes

Always call $next($request) to pass the request along.

Middleware can stop requests early by returning a response like redirect or error.

Summary

Middleware filters requests to protect and control access.

It checks or changes requests before they reach your app.

You use middleware to keep your app safe and organized.

Practice

1. What is the main purpose of middleware in a Laravel application?

easy

A. To filter and check requests before they reach the app

B. To store data permanently in the database

C. To create user interface components

D. To compile CSS and JavaScript files

Solution

1. Step 1: Understand middleware role

   Middleware acts as a gatekeeper that processes requests before they reach the main app logic.

2. Step 2: Identify main purpose

   Its main job is to filter, check, or modify requests to protect or control access.

3. Final Answer:

   To filter and check requests before they reach the app -> Option A

4. Quick Check:

   Middleware filters requests = D [OK]

Hint: Middleware acts before app logic to filter requests [OK]

Common Mistakes:

• Confusing middleware with database storage
• Thinking middleware builds UI components
• Assuming middleware compiles assets

2. Which of the following is the correct way to apply middleware to a route in Laravel?

easy

A. $router->get('/home')->middleware('auth');

B. Route::get('/home')->middleware('auth');

C. Route::get('/home')->useMiddleware('auth');

D. $router->get('/home')->use('auth');

Solution

1. Step 1: Recall Laravel route syntax

   Laravel uses the Route facade with methods like get() and middleware() to assign middleware.

2. Step 2: Identify correct chaining method

   The correct method to apply middleware is middleware(), not useMiddleware() or use().

3. Final Answer:

   Route::get('/home')->middleware('auth'); -> Option B

4. Quick Check:

   Correct middleware method = C [OK]

Hint: Use Route::get()->middleware('name') to apply middleware [OK]

Common Mistakes:

• Using $router instead of Route facade
• Using useMiddleware() instead of middleware()
• Using use() which is not a Laravel method

3. Given this middleware that blocks requests without a 'token' header, what will happen if a request lacks the token?

public function handle($request, Closure $next) {
    if (!$request->hasHeader('token')) {
        return response('Unauthorized', 401);
    }
    return $next($request);
}

medium

A. The request is stopped with a 401 Unauthorized response

B. The request is redirected to the login page

C. The request proceeds normally to the app

D. The request causes a server error

Solution

1. Step 1: Analyze middleware condition

   The middleware checks if the request has a 'token' header; if not, it returns a 401 response immediately.

2. Step 2: Understand request flow

   Without the token header, the middleware stops the request and sends back 'Unauthorized' with status 401.

3. Final Answer:

   The request is stopped with a 401 Unauthorized response -> Option A

4. Quick Check:

   Missing token header = 401 response [OK]

Hint: Middleware returns 401 if token header missing [OK]

Common Mistakes:

• Assuming request proceeds without token
• Thinking it redirects instead of returning 401
• Expecting a server error instead of controlled response

4. This middleware is intended to block requests without 'X-API-KEY' header. What is wrong with it?

public function handle($request, Closure $next) {
    if ($request->header('X-API-KEY') == null) {
        $next($request);
    }
    return response('Forbidden', 403);
}

medium

A. It never calls $next() for valid requests

B. It should return 401 instead of 403

C. It uses wrong header name case

D. It returns 403 even when the header exists

Solution

1. Step 1: Trace middleware logic

   If header is null, it calls $next($request) but does not return it, so execution continues.

2. Step 2: Identify flow error

   After calling $next(), it always returns 403 response, so even valid requests get blocked.

3. Final Answer:

   It returns 403 even when the header exists -> Option D

4. Quick Check:

   Missing return before $next causes wrong 403 always [OK]

Hint: Always return $next($request) to continue request [OK]

Common Mistakes:

• Not returning $next() call
• Misunderstanding header case sensitivity (Laravel handles case)
• Confusing 401 and 403 status codes

5. You want to create middleware that only allows requests with a 'role' header set to 'admin' or 'editor'. Which code snippet correctly implements this filter?

hard

A. public function handle($request, Closure $next) {
if ($request->header('role') === 'admin' && $request->header('role') === 'editor') {
return $next($request);
}
return response('Forbidden', 403);
}

B. public function handle($request, Closure $next) {
if ($request->header('role') == 'admin' || 'editor') {
return $next($request);
}
return response('Forbidden', 403);
}

C. public function handle($request, Closure $next) {
if (in_array($request->header('role'), ['admin', 'editor'])) {
return $next($request);
}
return response('Forbidden', 403);
}

D. public function handle($request, Closure $next) {
if ($request->header('role') != 'admin' || $request->header('role') != 'editor') {
return response('Forbidden', 403);
}
return $next($request);
}

Solution

1. Step 1: Understand role check logic

   The middleware should allow requests if the 'role' header is either 'admin' or 'editor'.

2. Step 2: Evaluate each option's condition

   public function handle($request, Closure $next) { if (in_array($request->header('role'), ['admin', 'editor'])) { return $next($request); } return response('Forbidden', 403); } uses in_array() correctly to check if role is in allowed list. public function handle($request, Closure $next) { if ($request->header('role') == 'admin' || 'editor') { return $next($request); } return response('Forbidden', 403); } has incorrect condition syntax. public function handle($request, Closure $next) { if ($request->header('role') === 'admin' && $request->header('role') === 'editor') { return $next($request); } return response('Forbidden', 403); } requires role to be both 'admin' and 'editor' simultaneously, which is impossible. public function handle($request, Closure $next) { if ($request->header('role') != 'admin' || $request->header('role') != 'editor') { return response('Forbidden', 403); } return $next($request); } logic is inverted and will block valid roles.

3. Final Answer:

   Uses in_array() to correctly filter 'admin' or 'editor' roles -> Option C

4. Quick Check:

   Use in_array() for multiple allowed values [OK]

Hint: Use in_array() to check multiple allowed roles [OK]

Common Mistakes:

• Using || incorrectly without full comparisons
• Checking for both roles with && instead of ||
• Inverting logic causing wrong blocking