Как правильно обрабатывать запрещённый доступ в веб-приложениях на PHP

Расширенные примеры обработки ошибок доступа

Пример 1. Класс Auth с проверкой ролей и хранением в БД

Для реального проекта рекомендуется вынести логику аутентификации и авторизации в отдельный класс. Ниже показана упрощённая реализация с проверкой прав по таблице 'roles'.

<?php
class Auth {
    private $db;
    private $userId;
    private $role;

    public function __construct(PDO $db) {
        $this->db = $db;
        session_start();
        $this->userId = $_SESSION['user_id'] ?? null;
        $this->role = $_SESSION['user_role'] ?? null;
    }

    /**
     * Проверяет, авторизован ли пользователь
     */
    public function isAuthenticated(): bool {
        return $this->userId !== null;
    }

    /**
     * Проверяет, имеет ли пользователь одну из указанных ролей
     */
    public function hasRole(string ...$roles): bool {
        return in_array($this->role, $roles);
    }

    /**
     * Принудительная авторизация: редирект на login, если не авторизован
     */
    public function requireAuth(): void {
        if (!$this->isAuthenticated()) {
            header('Location: /login.php');
            exit;
        }
    }

    /**
     * Принудительная роль: завершает с 403, если роль не подходит
     */
    public function requireRole(string ...$roles): void {
        $this->requireAuth();
        if (!$this->hasRole(...$roles)) {
            http_response_code(403);
            include 'errors/403.html';
            exit;
        }
    }
}

// Использование в контроллере
$auth = new Auth($pdo);
$auth->requireRole('admin', 'moderator');
// Дальнейший код - только для администраторов и модераторов
?>

Результат: при попытке доступа пользователя с ролью 'user' на страницу с requireRole('admin','moderator') будет показана страница 403.html или произойдёт редирект на login, если пользователь не авторизован.

Пример 2. Middleware для REST API с использованием Psr-7

В API (например, на Slim Framework) часто используют промежуточное ПО для проверки JWT-токена и прав. Пример на чистом PHP без фреймворка:

<?php
// middleware.php
function authMiddleware(callable $next, array $allowedRoles = []): callable {
    return function ($request) use ($next, $allowedRoles) {
        $token = $request['token'] ?? '';
        $user = validateToken($token); // возвращает массив с id и role

        if (!$user) {
            http_response_code(401);
            echo json_encode(['error' => 'Требуется авторизация']);
            exit;
        }

        if (!empty($allowedRoles) && !in_array($user['role'], $allowedRoles)) {
            http_response_code(403);
            echo json_encode(['error' => 'Доступ запрещён']);
            exit;
        }

        // Передаём управление следующему обработчику
        return $next($request, $user);
    };
}

// Пример использования
$handleRequest = authMiddleware(function ($req, $user) {
    // Защищённый endpoint
    echo json_encode(['message' => 'Привет, ' . $user['name']]);
}, ['admin']);

$handleRequest($_GET);
?>

Если токен отсутствует или невалиден - статус 401. Если роль не подходит - 403. Иначе возвращается JSON с приветствием.

Пример 3. ACL с хранением в базе данных и кешированием

Для больших систем ACL выгодно хранить в таблице 'permissions' (role, resource, access). Пример выборки и проверки:

<?php
class Acl {
    private $pdo;
    private $cache = [];

    public function __construct(PDO $pdo) {
        $this->pdo = $pdo;
    }

    public function hasAccess(string $role, string $resource): bool {
        $key = $role . '|' . $resource;
        if (!isset($this->cache[$key])) {
            $stmt = $this->pdo->prepare(
                'SELECT 1 FROM permissions WHERE role = ? AND resource = ?'
            );
            $stmt->execute([$role, $resource]);
            $this->cache[$key] = (bool) $stmt->fetchColumn();
        }
        return $this->cache[$key];
    }
}

// Применение
$acl = new Acl($pdo);
if (!$acl->hasAccess($_SESSION['user_role'], 'admin_users')) {
    http_response_code(403);
    exit('Недостаточно прав для управления пользователями.');
}
?>

Кеширование в массиве предотвращает повторные запросы к БД для одного и того же сочетания роль+ресурс в рамках одного запроса.

Пример 4. Использование .htaccess для перенаправления на PHP-обработчик с проверкой

Можно настроить сервер так, чтобы все запросы к защищённой директории передавались центральному скрипту, который проверяет права, а затем подключает нужный файл (если права есть).

# .htaccess в папке /protected/
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ /check_access.php?file=$1 [L,QSA]

<?php
// check_access.php
$file = $_GET['file'] ?? '';
$real_path = __DIR__ . '/' . basename($file); // предотвращаем path traversal

if (!is_file($real_path)) {
    header('HTTP/1.0 404 Not Found');
    exit('Файл не найден');
}

// Проверка сессии
session_start();
if (empty($_SESSION['user_id'])) {
    header('HTTP/1.0 403 Forbidden');
    exit('Доступ запрещён');
}

// Если проверка пройдена - подключаем файл
include $real_path;
?>

Посетитель по адресу /protected/secret.php получает сначала вызов check_access.php. Если не авторизован - 403, иначе отдаётся содержимое secret.php.