Админ-панели и CMS

01Что нужно любой админке

Начинайте с пользователей админки, а не с таблиц базы данных. Оператору, который обрабатывает заказы, нужен быстрый список заказов с фильтрами по статусу и обновлениями в реальном времени. Контент-менеджеру нужны страницы, блог, медиа и SEO. Маркетологу — акции, сегменты и кампании. Руководителю — отчёты. За всеми ними стоят одни и те же строительные блоки: аутентификация (в идеале со вторым фактором или одноразовыми кодами для администраторов), роли и права, CRUD-экраны (create, read, update, delete) с поиском, фильтрами, сортировкой и пагинацией, массовые действия, медиатека, настройки, отчёты с экспортом и аудит-лог. Уведомления — web push или внутри приложения — сообщают сотрудникам о новых заказах или упавших синхронизациях.

• Списки: пагинация на сервере, фильтры в URL, чтобы представлениями можно было делиться.
• Формы: валидация на сервере, понятные ошибки, предупреждение о несохранённых изменениях.
• Массовые действия с подтверждением и сводкой того, что изменилось.

02Роли, права и аудит-логи

Роль — это именованный набор прав («оператор заказов», «редактор контента»); право — это одно действие над ресурсом, например orders.view или products.update. Проверяйте права на сервере в каждом запросе — скрыть кнопку в интерфейсе удобно, но это не безопасность. Держите имена прав единообразными, чтобы меню админки, маршруты и кнопки читали один и тот же список. Для чувствительных действий — возвратов, ручного изменения балансов, смены ролей — добавьте дополнительное трение: поле для причины, подтверждение, возможно, второго утверждающего. Аудит-лог записывает, кто что сделал, когда, с какой записью, и значения до и после. Когда в продакшене что-то идёт не так, аудит-лог превращает гадание в двухминутный поиск.

1// Laravel: one permission check per action, enforced on the server
2Route::middleware(['auth:admin', 'can:orders.refund'])
3    ->post('/admin/orders/{order}/refund', RefundOrderController::class);
4 
5// Audit every sensitive change with before/after values
6AuditLog::create([
7    'admin_id'   => $request->user()->id,
8    'action'     => 'order.refunded',
9    'subject'    => $order->getMorphClass().':'.$order->id,
10    'before'     => ['status' => $before],
11    'after'      => ['status' => $order->status, 'amount' => $amount],
12    'reason'     => $request->string('reason'),
13    'ip'         => $request->ip(),
14]);

03CRUD на основе конфигурации

Большинство экранов админки отличаются только полями и колонками. Вместо того чтобы писать каждый список и форму вручную, опишите ресурс в конфигурации: его API-эндпоинт, колонки списка, фильтры, поля формы с типами (text, number, select, rich text, image, slug, дерево категорий) и права. Универсальный движок рендерит список и форму по этому описанию, поэтому новый ресурс занимает минуты, а каждый экран получает одинаковую пагинацию, отображение ошибок валидации и массовые действия. На бэкенде универсальный ресурсный контроллер может обслуживать стандартный CRUD, а кастомные эндпоинты — обрабатывать особую логику. Оставьте запасной выход: некоторые экраны — страница деталей заказа, конструктор акций, дашборд — заслуживают кастомных компонентов, и система конфигурации должна позволять их подключать.

1export const brandsResource = {
2  name: "brands",
3  endpoint: "/admin/brands",
4  permission: "brands",
5  list: {
6    columns: ["logo", "name", "productsCount", "isActive"],
7    filters: [{ field: "isActive", type: "boolean" }],
8    search: ["name"],
9  },
10  form: [
11    { name: "name", type: "text", required: true, translatable: true },
12    { name: "slug", type: "slug", from: "name" },
13    { name: "logo", type: "media", accept: "image/*" },
14    { name: "description", type: "richText", translatable: true },
15    { name: "seo", type: "seo" },
16  ],
17} as const;

04Медиатека и SEO-поля

Медиатека хранит загрузки один раз и позволяет редакторам переиспользовать их: папки, поиск, кадрирование, замена (с сохранением работающих ссылок), alt-текст и отслеживание использования. Проверяйте загрузки по содержимому, а не только по расширению файла, ограничивайте размер и разрешение, удаляйте метаданные и генерируйте уменьшенные варианты, например WebP-миниатюры, в фоновой задаче. Когда сайт растёт, храните файлы в объектном хранилище (совместимом с S3) за CDN, а не на диске сервера приложения. SEO-поля нужны каждой публичной модели: slug, meta title, meta description, изображение для соцсетей, canonical URL и переключатель noindex, с разумными значениями по умолчанию, сгенерированными из контента. Админка также должна управлять редиректами, потому что переименованные slug иначе создают битые ссылки, а сайт должен генерировать sitemap из тех же данных.

05Отчёты и экспорт

Отчёты отвечают на бизнес-вопросы: продажи по дням и каналам, лучшие товары, новые и вернувшиеся покупатели, стоимость акций, среднее время доставки. Стройте их на запросах, рассчитанных на отчётность, — агрегированных таблицах, read-репликах или ночных сводках, — чтобы тяжёлый отчёт никогда не замедлял checkout. Всегда показывайте диапазон дат и часовой пояс и следите, чтобы цифры совпадали со списком заказов (одно и то же определение «оплачен» везде). Экспорт в Excel или CSV обязателен, потому что финансы и маркетинг живут в таблицах. Генерируйте большие выгрузки в задаче из очереди, стримьте строки, а не загружайте всё в память, и отправляйте ссылку на скачивание, когда файл готов. Выгрузки содержат персональные данные, поэтому защищайте их правами, короткоживущими ссылками и записью в аудит-логе.

06Встроенная CMS или headless CMS?

CMS (система управления контентом) позволяет людям без навыков разработки редактировать страницы и контент. Встроенная CMS живёт внутри вашей собственной админки и базы данных: страницы, блог, FAQ, баннеры и блоки рядом с товарами и заказами. Она идеальна, когда контент тесно связан с коммерческими данными, и ничего не стоит дополнительно. Headless CMS (Contentful, Sanity, Strapi, Payload) — это отдельный сервис, который хранит контент и отдаёт его через API; он хорош для редакционных команд, богатых блочных макетов, превью и процессов согласования. Часто встречается гибрид: структурированные бизнес-данные в собственном бэкенде, редакционный контент — в headless CMS. Что бы вы ни выбрали, моделируйте контент как типизированные блоки, а не как одно гигантское HTML-поле, чтобы дизайн контролировал фронтенд, а контент оставался переносимым.

07Авторизация за пределами ролей: scopes и policies

Role-based access control (RBAC) отвечает на вопрос «может ли этот человек делать возвраты по заказам?», но не на вопрос «может ли он делать возвраты по заказам этого филиала?». Реальной админке нужно и то и другое. Совмещайте права со scopes: у менеджера филиала есть orders.refund, ограниченное его филиалами, а пользователь-поставщик видит только свои товары. Реализуйте проверку в одном месте для каждого ресурса — в классе policy, — который получает пользователя, действие и запись, и применяйте тот же scope к запросам списков, чтобы люди даже не видели строки, которые им трогать нельзя. Это шаг к attribute-based access control (ABAC), где правила используют атрибуты пользователя и записи. Кэшируйте права пользователя в рамках запроса, инвалидируйте кэш при изменении ролей и пишите тесты на каждую чувствительную policy, потому что баги авторизации молчат, пока не приведут к утечке данных.

1// Laravel policy: permission plus scope in one place
2class OrderPolicy
3{
4    public function refund(Admin $admin, Order $order): bool
5    {
6        return $admin->can('orders.refund')
7            && $admin->branches()->whereKey($order->branch_id)->exists();
8    }
9}
10 
11// The same scope applied to list queries
12Order::query()
13    ->whereIn('branch_id', $admin->branches()->pluck('branches.id'))
14    ->latest()
15    ->paginate(50);

08Audit log, который выдержит разбор инцидента

Audit log полезен, только если ему доверяют. Пишите записи на сервисном слое, чтобы фиксировались изменения из экранов, API-вызовов, импортов и консольных команд. Сохраняйте diff изменённых полей, а не строки целиком, и маскируйте секреты и чувствительные персональные данные. Сделайте таблицу append-only: пользователь базы, под которым работает приложение, может вставлять, но не обновлять и не удалять, а очистка по сроку хранения запускается отдельной привилегированной задачей. Добавляйте к каждой записи request ID, чтобы одно действие админа, затронувшее десять записей, отслеживалось как одно событие. Для особо ценных действий логируйте и чтение — кто выгрузил список клиентов, кто просмотрел полный адрес держателя карты. Храните аудит достаточно долго для споров и требований регуляторов и обеспечьте поиск по записи, по человеку и по временному диапазону.

1-- Append-only for the application user
2REVOKE UPDATE, DELETE ON audit_logs FROM app_user;
3GRANT INSERT, SELECT ON audit_logs TO app_user;
4 
5CREATE INDEX audit_logs_subject_idx ON audit_logs (subject_type, subject_id, created_at DESC);
6CREATE INDEX audit_logs_actor_idx   ON audit_logs (admin_id, created_at DESC);

09Производительность админки на больших таблицах

Списки в админке часто становятся самой медленной частью системы: таблица заказов на миллионы строк, десяток фильтров и общий счётчик на каждой странице. Делайте индексы под фильтры, которыми реально пользуются, — обычно составные индексы, начинающиеся со статуса или филиала и заканчивающиеся датой создания. Точный общий счётчик на огромных отфильтрованных таблицах дорог; после определённого порога показывайте «много результатов» или оценку либо считайте асинхронно. Offset-пагинация деградирует на глубоких страницах, потому что база всё равно проходит пропущенные строки; keyset (cursor) пагинация остаётся быстрой. Избегайте N+1 запросов, подгружая через eager loading связи, которые показываются в колонках. Поиску по множеству текстовых колонок место в поисковом движке или полнотекстовом индексе, а не в цепочках LIKE. И наконец, тяжёлые дашборды выносите на read replica или в сводные таблицы, чтобы менеджер, обновляющий отчёты, никогда не замедлял оформление заказов.

• Логируйте медленные запросы админки и разбирайте их раз в месяц.
• Для выгрузок и бесконечной прокрутки предпочитайте cursor-пагинацию.
• Подгружайте через eager loading связи, используемые в колонках списков.

10Защита админки

Админка — самая мощная дверь в бизнес, поэтому ей нужны самые крепкие замки. Требуйте второй фактор для каждого аккаунта администратора. Делайте сессии админки короткими, с таймаутом бездействия, и запрашивайте повторную аутентификацию перед критичными действиями, такими как смена ролей или реквизитов для выплат. Подумайте о том, чтобы отдавать админку на отдельном поддомене, с более строгими cookies и, где это реально, с IP allowlist или VPN. Защищайтесь от CSRF при сессиях на cookies и от stored XSS из полей с rich text, санитизируя HTML на сервере по allowlist тегов. Загруженные файлы никогда не должны быть исполняемыми: храните их вне web root или в object storage и осторожно отдавайте загруженные пользователями SVG, потому что SVG может содержать скрипты. Мониторьте входы в админку и поднимайте алерт на новые устройства или «невозможные перемещения».