Права доступа определяют, кто и что может делать в системе: администратор видит всё, менеджер — только свои заказы, клиент — только свой личный кабинет. В многопользовательском приложении это критично: одна забытая проверка — и пользователь видит чужие данные; слишком жёсткие ограничения — и работать невозможно. Чтобы не было хаоса, доступ проектируют системно.
Ниже — как мы организуем роли и права в индивидуальной веб-системе на Laravel, используя штатные механизмы и проверенные библиотеки.
Роли и права: разница, которую важно понимать
Право (permission) — это конкретное действие: «создавать заказ», «удалять пользователя». Роль (role) — это набор прав под тип пользователя: «менеджер» = читать и создавать заказы, но не удалять. Такой подход (RBAC — управление доступом на основе ролей) позволяет менять права целой группы в одном месте, а не у каждого пользователя вручную.
Стандарт для Laravel — библиотека spatie/laravel-permission: она хранит роли и права в базе, привязывает их к пользователям и даёт удобные проверки в коде и в шаблонах.
Policies, Gates и Middleware: что где применять
В Laravel три встроенных инструмента авторизации, и у каждого своя роль:
| Инструмент | Когда применять | Пример |
|---|---|---|
| Policy (политика) | доступ к конкретной модели | «пользователь видит только свои заказы» |
| Gate | разовая проверка, не привязанная к модели | «доступ в админ-панель» |
| Middleware | защита групп роутов по роли | весь раздел /admin только для админов |
Политики идеальны для правила «свой/чужой» — они проверяют, принадлежит ли объект пользователю. Middleware закрывает целые разделы. Gates удобны для точечных проверок. Вместе они покрывают почти все сценарии без «самописных» костылей.
Принцип минимальных привилегий
Базовое правило безопасности (его же рекомендует OWASP): по умолчанию доступ запрещён, а выдаётся ровно столько прав, сколько нужно для работы. Это противоположность подходу «дадим всё, потом урежем» — урезать почти никогда не доходят руки, и система копит дыры. Поэтому каждый новый роут проходит проверку доступа при добавлении, а не «когда-нибудь потом».
Дисциплина важнее инструмента
Даже лучшая библиотека не спасёт, если проверки добавляют бессистемно. Наши правила:
- Каждый новый эндпоинт получает проверку доступа сразу.
- Проверка «свой/чужой» — через политику модели, а не вручную в контроллере.
- Роли и права описаны централизованно (в сидере), а не разбросаны по коду.
- Перед крупным релизом проводим аудит прав — проверяем, что нет «дыр» и лишних доступов.
Чек-лист прав доступа
- Используется ролевая модель (RBAC), а не проверки «по email».
- Роли и права хранятся централизованно (spatie/laravel-permission).
- Доступ к моделям — через Policies, разделы — через Middleware.
- По умолчанию запрещено; выдаётся минимум необходимого.
- Каждый роут проверяется при добавлении; перед релизом — аудит.
Система прав опирается на чистую архитектуру и защищает в том числе API. Нужна веб-система с несколькими типами пользователей и надёжным разграничением доступа — вот разработка индивидуальной веб-системы.