Challenge 3: Add an Admin Bypass With Gate::before() — Possible Solution
====================================================================

// app/Providers/AppServiceProvider.php

namespace App\Providers;

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

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Gate::before(function (User $user, string $ability) {
            if ($user->is_admin) {
                return true;  // grants EVERY permission check, for every ability, automatically
            }

            return null;  // defer to the normal Policy/Gate logic for non-admins
        });
    }
}

WHY THIS RUNS BEFORE INDIVIDUAL POLICY METHODS
---------------------------------------------------
Gate::before() registers a closure that Laravel's authorization system
calls FIRST, before checking any specific Policy method or Gate
definition, for EVERY authorization check made anywhere in the
application (via $this->authorize(), @can, $user->can(), Gate::allows(),
all of them). If the Gate::before() closure returns true or false
(a definitive answer), that answer is used immediately and the actual
Policy method (like BookPolicy::update() or AuthorPolicy::update()) is
never even called. If it returns null, Laravel falls through to checking
the normal, specific Policy or Gate logic as usual.

This means an admin user calling $this->authorize('update', $book) never
actually reaches BookPolicy::update()'s $user->id === $book->author_id
check at all — Gate::before() already returned true for them, short-
circuiting the entire rest of the authorization pipeline. This is why
the bypass needs to be added ONLY ONCE, in this single central location,
rather than needing an `|| $user->is_admin` clause manually added to
every single Policy method across every model in the application (Book,
Author, Publisher, and any future model) — a single Gate::before()
closure automatically applies to all of them, present and future,
without touching any individual Policy file.

WHY THIS WORKS
--------------
- Returning null (rather than false) for non-admin users is essential —
  returning false here would DENY every permission check for every
  non-admin user regardless of what their actual Policy methods say,
  which is the opposite of the intended behavior. null specifically means
  "I have no opinion, let the normal authorization logic decide."
- This directly parallels the "deny by default, explicitly allow"
  pattern from the OWASP course's Access Control chapter, just applied in
  reverse for a deliberate, centralized override — one clearly-defined
  bypass path (is_admin) rather than scattering admin-check logic across
  every Policy method individually, which would make it easy to
  accidentally forget the bypass on a newly added Policy.