Роли редакции и серверные токены

Оглавление серии

Разрешение отвечает на вопрос, кто может выполнить конкретную операцию. В Strapi следует различать административную панель, Content API и технические tokens: похожие названия ролей не делают их одной системой доступа. В «Редакционном доме» автор должен готовить текст, выпускающий — публиковать его, сервер сайта — читать нужные документы, а посетитель — получать только готовый HTML.

Результат урока — матрица доступа, по которой можно настроить локальную лабораторию без открытия черновиков всем посетителям. Схемы и статья прежние. Новых реальных сотрудников мы не приглашаем: для будущей проверки достаточно собственных локальных учебных учётных записей с разными ролями. Никакие tokens и пароли не входят в архив.

Редакторская роль управляет панелью

В Settings найдите административные роли RBAC и создайте роль Writer для подготовки Article. Разрешите чтение, создание и изменение чернового текста в пределах выбранных полей; не выдавайте управление пользователями, API tokens и настройками проекта. Роль Publisher получает операции выпуска, которые требуются вашему процессу. Возможности и условия конкретных административных прав сверяются по RBAC.

Не делайте всех сотрудников Super Admin ради удобства первого дня. Такая роль нужна для управления экземпляром, но работа над summary не требует возможности менять секреты или создавать новый token. Учебная лаборатория полезна именно тем, что позволяет увидеть ограничения заранее, пока потеря доступа затронет только вымышленные записи.

Проверьте, какие права нужны для связаных Author и Category. Автору Article может требоваться чтение справочников для выбора существующего значения, но не их массовое удаление. Аналогично загрузка иллюстрации может быть разрешена, а изменение всех файлов — ограничено. Одна операция на Article не описывает весь набор связанных действий редактора.

Административная учётная запись не является пользователем приложения Users & Permissions. Если в библиотеке нет регистрации посетителей, не создавайте её только ради работы редакторов. Две системы решают разные задачи: сотрудники панели управляют содержанием, внешние пользователи Content API могут иметь собственные функции приложения. В нашем проекте второй сценарий пока отсутствует.

Public и Authenticated остаются закрытыми

Откройте Users & Permissions roles. У Public отключите операции чтения Article, Author, Category и загрузки. У обычной Authenticated role также не включайте их. Наш сайт не обращается к этим коллекциям от имени браузера. Сервер использует отдельный token, поэтому закрытая Public role не препятствует его работе.

Здесь важно не переносить правила панели на API. Writer admin с правом редактировать статью не даёт анонимному GET право прочитать её. И выключенный Public create не означает, что Public find безопасно для черновиков. Разрешения следует обсуждать по конкретным endpoints и субъектам, а не словами «редактор имеет доступ» без уточнения системы.

Полный учебный файл specs/access-matrix.csv фиксирует решения, а не автоматически применяет их. Его строки переводятся в настройки вашей панели.

subject,article,author,category,upload,location
Public,none,none,none,none,No anonymous Content API
Authenticated,none,none,none,none,No customer authentication in this project
Site custom token,find/findOne,find/findOne,find/findOne,none,Server environment only
Temporary importer,find/create,find/create,find/create,none,Local empty CMS only then revoke
Writer admin,read/create/update drafts,read,read,create,Admin panel role
Publisher admin,read/update/publish,read,read,create,Admin panel role

Строка Site custom token содержит find/findOne только для нужных типов. Не выбирайте Full access для сервера, который ничего не записывает. Custom удобен тем, что ограничивает чтение и набором моделей. Общий Read-only token ограничивает действия чтением, но может быть шире выбранного каталога. Точные типы tokens и управление ими описаны в API Tokens.

Token принадлежит процессу

Создайте Content API token с именем editorial-site-local, понятным описанием и конечным сроком действия для лаборатории. Скопируйте его в site/.env, поле CMS_TOKEN. Не помещайте значение в templates.mjs, HTML-атрибут или query URL. Сервер отправляет Authorization при запросе к CMS; браузер видит только окончательный документ сайта.

После изменения token может требоваться перезапуск потребителя, если окружение читается при старте. Сам файл .env.example должен оставаться образцом с placeholders. Редакторский архив можно передать другому читателю, и тот создаст собственные credentials. Если архив содержит пригодный token, это уже доступ к конкретной CMS, а не воспроизводимый учебный набор.

Для импорта позднее создадим отдельный временный token с find/create в пустой локальной базе. Импортёр не использует credentials сайта, поскольку его операции шире. После наполнения token отзывается. Такой порядок позволяет продолжать чтение сайта, не сохраняя у его процесса возможность создавать новые статьи. Разные назначения требуют независимого управления сроками и отзывом.

Новые административные tokens текущей версии также не следует смешивать с Content API tokens. Документация разделяет доступ к admin routes и Content API. Даже если оба передаются как Bearer, область действия отличается. Наш потребитель не автоматизирует административную панель и не получает admin token. Форма Authorization — технический способ передачи, а не описание полномочий.

Наблюдаемые отказы

Ожидаемый успешный сценарий — сервер читает published Article, умеет populate имя Author и не имеет права создать Article. Без Authorization /api/articles должен отказать согласно закрытым Public permissions. Эти ответы нужно проверить в будущей локальной среде; в подготовке курса запросы не выполнялись. Отказ следует связать с конкретным отсутствующим правом, а не исправлять включением всех операций сразу.

Проверяйте также отрицательный сценарий записи. Если token сайта может выполнить POST, его набор permissions слишком широк для нашего контракта. Если связанные авторы исчезают только при populate, выясните право find Author. Для каждого симптома меняют минимально нужное решение. Такой способ диагностики сохраняет объяснимость матрицы и помогает заметить случайные расширения доступа.

Когда срок token заканчивается, сайт должен получить отказ CMS, а не незаметно перейти на Public permissions. Запишите процедуру замены: новый ограниченный token создаётся администратором, передаётся серверному окружению, затем прежний отзывается. Время пересечения выбирают по нуждам процесса. В лаборатории достаточно последовательной ручной замены; автоматическая ротация не реализована. Такое правило делает ограничение срока практичным: оно относится к управляемому доступу, а не к случайной будущей поломке каталога.

Read-only не означает опубликованные версии: server token потенциально читает drafts разрешённого типа. Поэтому граница публикации находится ещё и в нашем серверном коде. Простой query ?status=draft на сайте не передаётся в CMS. В двенадцатом уроке доступ к draft получит только отдельная подписанная ссылка с коротким сроком действия. Эта связь прав и архитектуры делает матрицу полезной: таблица описывает не только переключатели панели, но и место, где каждое полномочие используется.