Route admin and user for Marketplace Website

by

Summary

A student developer building a Laravel marketplace website asked how to properly route requests for Admin and User roles and noticed their lecturer flagged the default User model as incorrect. The core issue is implementing Role-Based Access Control (RBAC) on top of Laravel’s default authentication scaffolding. The lecturer’s critique of the User model likely stems from the absence of a role column needed to distinguish between administrators and standard users, making it impossible to enforce route segregation.

Root Cause

The primary technical deficiencies preventing proper routing separation are:

  • Missing Database Schema: The default users table migration lacks a role or is_admin column, which is essential for programmatic identification of user privileges.
  • Unprotected Routes: Laravel routes are public by default. Without Middleware, HTTP requests intended for administrators can be accessed by unauthenticated or low-privilege users.
  • Inadequate User Model: The provided User model uses the default $fillable attributes. It lacks a role relationship or accessor methods to check permissions, preventing the application logic from distinguishing the currently logged-in user’s capabilities.

Why This Happens in Real Systems

In production environments, this pattern occurs when developers rely on generic scaffolding (like php artisan make:auth or Breeze) without customizing it for specific business logic. Laravel provides a robust authentication system, but it is role-agnostic out of the box. Systems fail when developers assume the framework handles authorization logic, leading to “broken access control” where a user can simply change a URL to /admin/delete-user and execute privileged actions because the server never verified their role.

Real-World Impact

Failing to implement proper role routing leads to critical security and functional failures:

  • Security Breaches: Unauthorized users can access sensitive admin panels, delete data, or modify prices.
  • Data Integrity Loss: Users might manipulate other users’ orders or accounts if admin endpoints are not secured.
  • Logic Errors: The application displays incorrect UI elements (e.g., “Edit” buttons) or crashes if it assumes an admin-only property exists on a standard user object.

Example or Code

To fix the routing, you must first add the role to the database and then update the model and routes.

1. Update the Migration (Add Role):
You need to add a role column to store “admin” or “user”.

Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('email')->unique();
    $table->timestamp('email_verified_at')->nullable();
    $table->string('password');
    // Add this line for role management
    $table->string('role')->default('user'); 
    $table->rememberToken();
    $table->timestamps();
});

2. Update the User Model:
Add the role to the $fillable array so it can be set during registration.

protected $fillable = [
    'name',
    'email',
    'password',
    'role', // Ensure this is added
];

3. Define Admin Middleware:
Create Middleware to check the user’s role before allowing access.

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

class AdminMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        if (Auth::check() && Auth::user()->role == 'admin') {
            return $next($request);
        }
        return redirect('/')->with('error', 'You do not have admin permissions');
    }
}

4. Register Middleware and Apply to Routes:
Register the middleware in app/Http/Kernel.php (or bootstrap/app.php in Laravel 11+) and apply it to routes.

// routes/web.php
Route::middleware(['auth', 'admin'])->group(function () {
    Route::get('/admin/dashboard', [AdminController::class, 'dashboard']);
    Route::get('/admin/products', [AdminController::class, 'products']);
});

Route::get('/dashboard', [UserController::class, 'dashboard'])->middleware('auth');

How Senior Engineers Fix It

Senior engineers treat Authorization as a distinct concern from Authentication. They fix this by implementing a multi-layered approach:

  1. Database Schema Modification: They ensure the users table includes a role (or a pivot table for many-to-many roles) to persist permission state.
  2. Middleware Enforcement: They create explicit Middleware (e.g., AdminMiddleware) to guard routes. This ensures that even if a URL is guessed, the request is rejected at the HTTP kernel level.
  3. Authorization Policies: Beyond simple routing, they use Laravel Gates or Policies. This allows for fine-grained control (e.g., can('edit', $product)) inside controllers and views, rather than just checking if ($user->role == 'admin').
  4. Response Logic: They ensure that unauthorized requests return the correct HTTP status code (usually 403 Forbidden) rather than just redirecting, which is better for API consumption and debugging.

Why Juniors Miss It

Junior developers often miss this because:

  • Focus on Authentication: They concentrate heavily on getting the user “logged in” (Authentication) and assume that once logged in, all users are the same.
  • Lack of “Trust Boundaries”: Juniors often trust that the frontend UI will hide admin buttons. They don’t realize they must also protect the backend endpoints, as a user can easily bypass the UI and send a request directly to the server.
  • Framework Assumption: They assume Laravel handles authorization automatically because it handles authentication so well.
  • Code Snippet Blindness: They copy-paste the default User model without reading the PHPDoc comments or thinking about what data the application actually needs to function securely.