Middleware vs Gates/Policies

<?php
// Middleware checks if user CAN ACCESS the route
// app/Http/Middleware/EnsureUserIsSubscribed.php
class EnsureUserIsSubscribed
{
    public function handle(Request $request, Closure $next)
    {
        // Check user's subscription status (not a specific resource)
        if (!$request->user() || !$request->user()->isSubscribed()) {
            return redirect('subscribe')
                ->with('error', 'You need an active subscription');
        }
        
        // User is subscribed, continue to controller
        return $next($request);
    }
}

// Usage in routes:
Route::middleware(['auth', 'subscribed'])->group(function () {
    Route::get('/premium/courses', [CourseController::class, 'index']);
    Route::get('/premium/videos', [VideoController::class, 'index']);
    Route::get('/premium/downloads', [DownloadController::class, 'index']);
});

// Middleware runs BEFORE any controller
// It doesn't care about WHICH course or video
// Only cares about: "Is user subscribed?"

// Use Cases for Middleware:
// ✅ Authentication (is user logged in?)
// ✅ Email verification (is email verified?)
// ✅ Subscription status (is subscription active?)
// ✅ Rate limiting (has user exceeded API limits?)
// ✅ Role checking (is user an admin?) - broad check

<?php
// Policy checks if user CAN PERFORM ACTION on SPECIFIC resource
// app/Policies/PostPolicy.php
class PostPolicy
{
    // Can this user update THIS specific post?
    public function update(User $user, Post $post): bool
    {
        // Only the author or admins can update
        return $user->id === $post->user_id 
            || $user->isAdmin();
    }
    
    // Can this user delete THIS specific post?
    public function delete(User $user, Post $post): bool
    {
        // Only admins can delete
        return $user->isAdmin();
    }
    
    // Can this user publish THIS specific post?
    public function publish(User $user, Post $post): bool
    {
        // Only the author can publish their own draft
        return $user->id === $post->user_id 
            && $post->status === 'draft';
    }
}

// Usage in controller:
class PostController extends Controller
{
    public function update(Request $request, Post $post)
    {
        // Check authorization for THIS specific post
        $this->authorize('update', $post);
        
        // If we reach here, user is authorized
        $post->update($request->validated());
        
        return redirect()->route('posts.show', $post);
    }
}

// Policy runs INSIDE the controller
// It knows about the SPECIFIC post being updated
// Answers: "Can THIS user update THIS post?"

// Use Cases for Policies:
// ✅ Editing specific models (can edit THIS post?)
// ✅ Deleting specific resources (can delete THIS comment?)
// ✅ Viewing private content (can view THIS draft?)
// ✅ Resource ownership (is THIS user the owner?)

<?php
// Gates are for simple, non-model authorization
// app/Providers/AuthServiceProvider.php
class AuthServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        // Define a gate for admin access
        Gate::define('access-admin-panel', function (User $user) {
            return $user->role === 'admin';
        });
        
        // Define a gate for feature flags
        Gate::define('use-beta-features', function (User $user) {
            return $user->beta_tester || $user->isAdmin();
        });
        
        // Define a gate for time-based access
        Gate::define('post-after-hours', function (User $user) {
            $hour = now()->hour;
            return $user->isAdmin() || ($hour >= 9 && $hour <= 17);
        });
    }
}

// Usage in controllers:
class AdminController extends Controller
{
    public function index()
    {
        // Simple check not tied to a specific model
        if (Gate::denies('access-admin-panel')) {
            abort(403, 'Access denied');
        }
        
        return view('admin.dashboard');
    }
}

// Usage in Blade views:
@can('use-beta-features')
    <a href="/beta/new-editor">Try Beta Editor</a>
@endcan

// Gates vs Policies:
// Gates:     Simple, not tied to models
// Policies:  Complex, tied to specific model instances

<?php
// Real-world blog platform example

// Step 1: Route with middleware (request-level check)
Route::middleware(['auth', 'verified'])->group(function () {
    Route::resource('posts', PostController::class);
});
// Middleware asks: "Is user logged in and verified?"

// Step 2: Controller with policy (resource-level check)
class PostController extends Controller
{
    public function edit(Post $post)
    {
        // Policy asks: "Can THIS user edit THIS specific post?"
        $this->authorize('update', $post);
        
        return view('posts.edit', compact('post'));
    }
    
    public function update(Request $request, Post $post)
    {
        $this->authorize('update', $post);
        
        $post->update($request->validated());
        
        return redirect()->route('posts.show', $post);
    }
    
    public function destroy(Post $post)
    {
        $this->authorize('delete', $post);
        
        $post->delete();
        
        return redirect()->route('posts.index');
    }
}

// Security layers:
// Layer 1 (Middleware): Is user authenticated and verified?
// Layer 2 (Policy):     Can THIS user modify THIS post?

// This is the Laravel way:
// ✅ Middleware for broad access control
// ✅ Policies for specific resource permissions
// ✅ Together they create a secure system

// Timeline of a request to edit a post:
// 1. Middleware checks if user is logged in → ✓
// 2. Middleware checks if email is verified → ✓
// 3. Controller loads the specific post → ✓
// 4. Policy checks if THIS user can edit THIS post → ✓
// 5. Edit view is shown