Why middleware filters requests in Laravel - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why does middleware filter requests in Laravel?

Middleware in Laravel acts like a gatekeeper for incoming requests. What is the main reason Laravel uses middleware to filter requests?

A To generate HTML views from controllers

B To speed up database queries automatically

C To check and modify requests before they reach the application logic

D To store user data permanently on the server

💡 Hint

Think about how middleware can control access or change requests before the app handles them.

Middleware filters requests to check or modify them before they reach the main application. This helps with tasks like authentication, logging, or modifying headers.

❓ component_behavior

intermediate

What happens if middleware denies a request?

In Laravel, if a middleware decides a request should not proceed, what happens next?

A The request is logged but still processed normally

B The request continues to the controller but with a warning

C The middleware crashes the application

D The request is stopped and a response is sent back immediately

💡 Hint

Middleware can block requests to protect the app.

If middleware denies a request, it stops the request from going further and sends a response immediately, like a 403 error for unauthorized access.

❓ state_output

advanced

What is the output when middleware modifies a request header?

Consider a Laravel middleware that adds a custom header X-Custom-Header: Hello to every request. What will the controller receive?

Laravel

<?php
// Middleware handle method
public function handle($request, Closure $next) {
    $request->headers->set('X-Custom-Header', 'Hello');
    return $next($request);
}

// Controller method
public function index(Request $request) {
    return $request->header('X-Custom-Header');
}

A "Hello"

B null

C "x-custom-header"

D Throws an error

💡 Hint

Middleware can add or change headers before the controller sees the request.

The middleware sets the header before passing the request on, so the controller receives the modified header value "Hello".

📝 Syntax

advanced

Identify the correct middleware syntax to allow only authenticated users

Which middleware code snippet correctly checks if a user is authenticated and redirects if not?

A

public function handle($request, Closure $next) {
    if (!auth()->check()) {
        return redirect('login');
    }
    return $next($request);
}

B

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

C

public function handle($request, Closure $next) {
    if (auth()->guest()) {
        return redirect('login');
    }
    return $next($request);
}

D

public function handle($request, Closure $next) {
    if (auth()->check) {
        return redirect('login');
    }
    return $next($request);
}

💡 Hint

Check the correct method to verify authentication and syntax for method calls.

Option A uses auth()->check() correctly to verify if the user is logged in. If not, it redirects to login. Other options have wrong methods or syntax.

🔧 Debug

expert

Why does this middleware not stop unauthenticated users?

Given this middleware code, why does it fail to block unauthenticated users?

Laravel

public function handle($request, Closure $next) {
    if (auth()->check()) {
        return redirect('login');
    }
    return $next($request);
}

A It uses the wrong method to check authentication

B It redirects authenticated users instead of unauthenticated ones

C It does not return the next middleware

D It throws a syntax error because of missing semicolons

💡 Hint

Look carefully at the condition and who it redirects.

The condition auth()->check() returns true for authenticated users, so it redirects them instead of blocking unauthenticated users. The logic is reversed.