Права доступа и роли в Drupal: разбор на живом сайте

На новостном сайте автор должен создавать только свои материалы, редактор — проверять и публиковать все, а администратор — менять конфигурацию. Если выдать роли наугад, автор увидит чужие черновики, редактор получит доступ к настройкам сайта, а исправление ошибки превратится в поиск по сотням разрешений. Разберём рабочую схему для Drupal 10.3+ и 11.x на примере сайта с типом материала «Статья», редакцией и публикацией через Content Moderation.

Сценарий: три роли и один тип материала

Представим сайт редакции. В нём есть три группы пользователей:

• Автор пишет собственные статьи и отправляет их на проверку.
• Редактор открывает материалы всех авторов, исправляет текст и переводит статьи в опубликованное состояние.
• Менеджер сайта управляет пользователями, структурой и конфигурацией Drupal.

Гостям сайта доступен опубликованный контент. Зарегистрированным пользователям без специальной роли дополнительные права не нужны. Это важная граница: роль «аутентифицированный пользователь» автоматически применяется ко всем вошедшим в систему, поэтому её не стоит превращать в универсальную рабочую роль.

Безопасная роль даёт пользователю ровно тот маршрут, который ему нужен: создать, проверить или опубликовать материал. Всё остальное остаётся закрытым.

Термин: разрешение — отдельное право Drupal на действие или доступ к разделу. Роль — набор разрешений, который назначается пользователю. Один пользователь может иметь несколько ролей, а итоговый доступ обычно складывается из разрешений всех назначенных ролей.

Как собрать схему ролей в Drupal

1. Опишите действия, а не должности

Сначала составьте список операций для каждой группы. Не начинайте с кнопки «дать все права». Для нашего сайта достаточно такой матрицы:

Последняя строка требует отдельного решения. Полный доступ к конфигурации не нужен менеджеру контента, если он только следит за публикациями. В небольшой команде эту роль можно оставить владельцу сайта, а менеджеру выдать только пользовательские и контентные права.

2. Создайте роли

Откройте раздел управления пользователями и ролями. В стандартной административной теме Drupal путь обычно выглядит как People → Roles, а русские названия зависят от перевода интерфейса. Создайте роли «Автор», «Редактор» и «Менеджер сайта».

Не переименовывайте встроенные роли без причины. Для публичного посетителя и обычного вошедшего пользователя Drupal уже использует роли «Анонимный пользователь» и «Аутентифицированный пользователь». Специальные рабочие права лучше добавлять отдельными ролями: так проще проверить и отозвать доступ.

3. Выдайте автору минимальный набор

На странице разрешений найдите права, относящиеся к типу материала «Статья». Для автора обычно нужны создание материала и редактирование собственного материала. Если автор должен удалять свои черновики, добавьте право удаления собственных материалов; право удаления любых материалов ему не нужно.

Если на сайте включён Content Moderation, проверьте разрешения переходов рабочего процесса. Автору можно разрешить переводить собственную статью из черновика в состояние вроде «На проверке», но не в опубликованное состояние. Точные названия переходов зависят от настроенного рабочего процесса и установленных модулей.

Проверка: войдите тестовым пользователем с ролью «Автор». Он должен видеть форму создания статьи, собственный материал и доступный переход на проверку. В списке материалов не должны открываться чужие черновики.

4. Настройте редактора

Редактору добавьте создание и редактирование статей, в том числе материалов других авторов. Затем разрешите нужный переход рабочего процесса — например, из состояния «На проверке» в «Опубликовано». Если редактор должен только проверять публикации, не выдавайте ему права управления ролями, модулями и конфигурацией.

Отдельно проверьте доступ к непропубликованным материалам. Возможность редактировать чужие материалы и возможность видеть все черновики не всегда совпадают: Drupal показывает отдельные разрешения, а дополнительные модули могут добавлять собственные ограничения.

Проверка: тестовый редактор видит статью автора до публикации, может изменить её и выполнить разрешённый переход. Разделы управления модулями и разрешениями ему недоступны.

5. Ограничьте менеджера сайта

Менеджеру назначьте только те административные права, за которые он отвечает. Если ему нужно создавать пользователей, дайте соответствующее право. Право управления разрешениями и конфигурацией выдавайте только человеку, который понимает последствия: одна галочка может открыть всем пользователям изменение содержимого или доступ к закрытым данным.

Полный административный доступ не стоит использовать как замену проектированию ролей. В Drupal он удобен для владельца сайта и аварийных работ, но плохо подходит для ежедневной редакционной деятельности.

Проверка: менеджер может выполнить свои рабочие операции, но вы понимаете, какие именно разделы ему открыты. Для проверки используйте отдельную тестовую учётную запись, а не собственный аккаунт администратора.

Что выбрать: широкие или узкие роли

Если разница между пользователями выражается только в порядке публикации, начните с ролей и Content Moderation. Если нужно ограничить доступ по разделу, языку, владельцу или группе, одних ролей может быть мало: заранее проверьте возможности конкретного модуля и его совместимость с вашей версией Drupal.

Что чаще всего ломается

Редактор видит меню, но не может выполнить действие

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

Автор публикует материал напрямую

Частая причина — право публикации осталось у роли «Аутентифицированный пользователь» или автор получил широкое разрешение из другого модуля. Просмотрите эффективные роли тестового пользователя и уберите публикацию из общей роли. После изменения выйдите из аккаунта и войдите снова: старые страницы и меню могут оставаться в кеше.

Пользователь видит чужие материалы

Проверьте различие между правами на создание, редактирование собственных материалов, редактирование любых материалов и просмотр непропубликованного содержимого. Не ограничивайтесь проверкой списка: откройте прямую ссылку на чужой черновик и попробуйте выполнить доступные действия.

После установки модуля появились новые права

Модули Drupal регистрируют собственные разрешения. После установки или обновления откройте страницу разрешений заново и проверьте новые строки. Особенно внимательно смотрите на права администрирования, экспорт конфигурации, просмотр пользовательских данных и массовые операции.

Изменение права не заметно сразу

Очистите кеши Drupal, если интерфейс или доступ ведут себя по-старому, затем повторите проверку в приватном окне браузера. Не используйте для теста аккаунт с ролью администратора: его доступ может обходить обычные ограничения и маскировать ошибку настройки.

Где схема ролей ломается

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

Ещё одна граница — пользовательские поля и персональные данные. Право редактировать материал может открыть поля, которые автору видеть не нужно. Проверьте отображение формы и страницы от имени каждой роли, включая скрытые административные поля. Инвалидация кеша после изменения прав — отдельная задача; здесь важна только проверка фактического доступа.

Что сделать дальше

Создайте на копии сайта по одному тестовому пользователю для каждой роли и сохраните сценарий проверки: создать материал, открыть чужой черновик, изменить материал, выполнить переход, удалить запись и открыть административные разделы. Повторите его после установки каждого модуля и перед выпуском обновлений Drupal.

Для Drupal 10.3+ и 11.x полезно также зафиксировать список ролей и разрешений в документации проекта. В продакшене смотрите не только на то, что пользователь может открыть, но и на журналы доступа, неожиданные изменения ролей и появление новых разрешений после обновлений. Чем меньше в системе широких ролей, тем быстрее вы найдёте источник ошибки.