Challenge 3: Fix a Form Missing @csrf — Possible Solution
====================================================================

<!-- BEFORE — missing @csrf, every submission fails -->

<form method="POST" action="{{ route('books.store') }}">
  <input type="text" name="title">
  <button type="submit">Save</button>
</form>

<!-- AFTER — fixed -->

<form method="POST" action="{{ route('books.store') }}">
  @csrf
  <input type="text" name="title">
  <button type="submit">Save</button>
</form>

THE EXACT HTTP STATUS CODE, AND HOW IT DIFFERS FROM DJANGO
---------------------------------------------------------------
Laravel returns HTTP 419 "Page Expired" when the VerifyCsrfToken
middleware can't find a valid CSRF token on an incoming POST/PUT/PATCH/
DELETE request. This is Laravel's own distinct status code choice for
this situation — technically a non-standard, framework-specific usage of
the 4xx range (419 isn't part of the official HTTP status code registry;
Laravel repurposes it specifically to mean "CSRF token missing or
expired").

Django, facing the identical root cause (a POST request without the
csrfmiddlewaretoken value the CsrfViewMiddleware expects), instead
returns a standard HTTP 403 Forbidden with the message "CSRF verification
failed."

Both frameworks are protecting against the exact same attack using the
exact same synchronizer token pattern (from the dedicated CSRF course)
— the difference is purely which status code each framework's authors
chose to represent "the CSRF check failed," which is why it's worth
knowing Laravel's specific number (419) rather than assuming it matches
Django's 403 just because the underlying cause is identical.

WHY THIS WORKS
--------------
- @csrf compiles to a hidden <input type="hidden" name="_token"
  value="...">  field containing the current session's CSRF token —
  VerifyCsrfToken middleware (already active in Laravel's default
  middleware stack, the same way CsrfViewMiddleware is active by default
  in Django) checks this token against the session on every
  state-changing request and rejects the request with a 419 if it's
  missing or doesn't match.
- Because CSRF protection is active project-wide by default in both
  frameworks, the ONLY thing a developer needs to remember per-form is
  the one template directive (@csrf in Blade, {% csrf_token %} in DTL) —
  not separate middleware setup per route, unlike Express's csurf package
  requiring explicit wiring.