Why middleware filters requests in Laravel - Visual Breakdown

Concept Flow - Why middleware filters requests

Incoming HTTP Request

↓

Middleware Layer

↓

Check Condition

↓

Allow Request

↓

Controller/Route

Middleware acts like a gatekeeper that checks or changes requests before they reach your app's main logic.

Execution Sample

Laravel

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

This middleware checks if the user is logged in; if not, it redirects to login, else it passes the request on.

Execution Table

Step	Action	Request State	Condition Checked	Result	Next Step
1	Receive HTTP request	Original request	N/A	Start middleware	Check user authentication
2	Check if user is logged in	Original request	$request->user() exists?	No user found	Redirect to login
3	Redirect to login	Original request	N/A	Response sent: redirect	End middleware
4	If user found	Original request	$request->user() exists?	User found	Pass request to next middleware or controller
5	Pass request forward	Original request	N/A	Request continues	Controller handles request

💡 Middleware stops request if user not logged in; otherwise, request proceeds to controller.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
$request->user()	null or user object	null (no user)	user object (authenticated)	user object or null

Key Moments - 2 Insights

Why does middleware sometimes stop the request instead of letting it continue?

Middleware can stop the request to protect routes, like redirecting unauthenticated users as shown in step 2 and 3 of the execution table.

What happens if middleware modifies the request?

Middleware can change the request before passing it on, but in this example it only checks and redirects; see step 5 where the request continues unchanged.

Visual Quiz - 3 Questions

Look at the execution table, what happens at step 3?

A The request is redirected to login

B The request is passed to the controller

C The user is authenticated

D The middleware modifies the request

💡 Hint

Check the 'Result' column at step 3 in the execution table.

At which step does the middleware decide to allow the request to continue?

A Step 2

B Step 4

C Step 3

D Step 1

💡 Hint

Look for where the condition '$request->user() exists?' is true in the execution table.

If the user is authenticated, what will the variable tracker show after step 4?

A null

B redirect response

C user object

D empty

💡 Hint

Refer to the variable tracker row for '$request->user()' after step 4.

Concept Snapshot

Middleware filters requests before they reach your app.
It can check conditions like user login.
If conditions fail, it can stop or redirect the request.
If conditions pass, it lets the request continue.
This helps protect routes and modify requests safely.

Full Transcript

Middleware in Laravel acts as a filter for incoming HTTP requests. When a request arrives, middleware checks conditions such as whether the user is logged in. If the user is not authenticated, middleware can stop the request and redirect it to a login page. If the user is authenticated, middleware passes the request on to the next middleware or the controller. This process helps protect parts of your app and allows you to modify requests before they reach your main logic.

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