Права в Drupal: как внедрить роли без лишнего доступа
В Drupal легко выдать редактору доступ к нужному разделу — и случайно разрешить ему менять чужие материалы. Разбираем, как спроектировать роли, проверить права на тестовых аккаунтах и не превратить доступы в набор исключений.
Сначала роли, потом галочки
В Drupal права обычно внедряют не с чистого листа, а поверх привычки выдавать доступ конкретному человеку по просьбе. Так редактору открывают создание материалов, затем добавляют возможность редактировать любые публикации, а после ухода сотрудника никто не помнит, зачем это разрешение понадобилось. В Drupal 10 и 11 безопаснее начинать с задач пользователей: составить роли, выдать каждой минимальный набор разрешений и проверить результат под отдельными учётными записями.
Это не отчёт о конкретном внедрении с выдуманными цифрами, а практический сценарий для сайта, где над материалами работают редакторы, авторы и администраторы. Его цель — чтобы человек мог выполнить свою работу, но не получал доступ к чужим публикациям и настройкам сайта по умолчанию.
Что именно настраивает Drupal
В ядре Drupal роли объединяют пользователей, а разрешения задают, какие действия доступны каждой роли. Настройки находятся в разделе управления людьми и разрешениями; точный путь в административном интерфейсе зависит от конфигурации сайта, но стандартный адрес страницы разрешений — /admin/people/permissions. Там разрешения сгруппированы по модулям, а для материалов часть пунктов зависит от включённых типов контента.
Не смешивайте доступ к странице с правом менять её содержимое. Например, разрешение на просмотр опубликованного содержимого не означает, что пользователь может создавать материалы. А право создавать материал одного типа не означает автоматически право редактировать любой материал этого типа.
Для контентных типов Drupal формирует отдельные разрешения на создание, редактирование и удаление материалов. Для некоторых действий есть варианты «собственные» и «любые»: они принципиально различаются. «Собственные» ограничивает действие материалами, автором которых является текущий пользователь; «любые» расширяет его на материалы других авторов.
Как спроектировать роли на рабочем сайте
Не создавайте роль на каждого сотрудника. Роль должна описывать устойчивую рабочую функцию, а не имя человека или разовую просьбу. Если одному сотруднику нужны права двух функций, назначьте ему две роли — но сначала проверьте, не складываются ли они в нежелательный доступ.
| Роль | Что ей обычно нужно | Что проверить отдельно |
|---|---|---|
| Автор | Создавать материалы своего типа и редактировать собственные | Может ли он удалять опубликованные материалы и просматривать черновики других авторов |
| Редактор | Проверять и менять материалы команды, работать с публикацией | Действительно ли нужно редактирование любых материалов, а не только публикация на этапе модерации |
| Администратор | Управлять конфигурацией и пользователями в рамках обязанностей | Не выдан ли административный доступ сотрудникам, которым достаточно редакторских прав |
Это стартовая схема, а не готовая матрица для любого сайта. Например, портал с несколькими редакциями может требовать разделения по подразделениям или типам материалов. Одних штатных ролей и разрешений может не хватить, чтобы ограничить доступ именно по такому признаку: прежде чем добавлять модуль для контроля доступа, сформулируйте правило и проверьте, поддерживает ли его выбранное решение.
План внедрения и проверки
- Опишите задачи. Запишите, какие типы материалов человек создаёт, что может менять и кто утверждает публикацию. Результат шага — короткая матрица «роль → действие → тип материала», без формулировок вроде «доступ ко всему нужному».
- Соберите роли по функциям. Создайте отдельные роли для устойчивых групп задач, например автора и редактора. Не используйте роль администратора как удобный способ обойти недостающие разрешения. Результат — список ролей, который можно объяснить без привязки к фамилиям сотрудников.
- Выдайте минимальный набор разрешений. На странице разрешений включайте только пункты, необходимые для заявленных задач. Внимательно различайте действия над собственными и любыми материалами; отдельно проверяйте создание, редактирование, удаление и просмотр неопубликованного содержимого. Результат — заполненная матрица, где каждое разрешение связано с конкретной задачей.
- Проверьте права на тестовых пользователях. Создайте по учётной записи для каждой роли и проверьте не только ожидаемый доступ, но и запрещённые действия: открыть чужой материал на редактирование, удалить публикацию, перейти к административным настройкам. Результат — автор видит доступные ему операции, а запрещённые действия действительно закрыты.
- Проверьте сочетание ролей и обновления конфигурации. Назначьте тестовому пользователю все роли, которые в реальности может получить один человек, и повторите негативные проверки. После изменения разрешений проверьте поведение снова: кэш и конфигурация сайта могут влиять на то, когда изменение станет заметно. Результат — тесты проходят и для отдельных ролей, и для их сочетаний.
Проверять доступ только по строкам в таблице разрешений недостаточно. Для контента важны и конкретный материал, и его автор, и статус публикации. Используйте тестовые записи с разными авторами и состояниями, а не единственную публикацию администратора.
Где типовая схема ломается
Редактору выдали «редактировать любые»
Это может решить проблему с проверкой чужого черновика, но одновременно открыть изменение материалов других авторов во всех подходящих типах контента. Если редактору нужно лишь согласовывать публикации, проверьте, можно ли организовать процесс через статусы и задачи редакции без столь широкого права. Само наличие рабочего сценария с модерацией не гарантирует, что доступ к редактированию ограничен нужным этапом.
Разрешения складываются неожиданно
Пользователь может состоять сразу в нескольких ролях. Поэтому недостаточно испытать автора и редактора по отдельности: проверьте их сочетание на тестовом аккаунте. Запрос «добавьте только одно право» тоже опасен, если не выяснить, какие разрешения у пользователя уже есть.
Сломался доступ после добавления модуля
Модуль, который меняет контроль доступа к содержимому, может влиять на поведение всей схемы. Не устанавливайте его как локальную заплатку без тестов: сначала проверьте совместимость с версией Drupal и другими модулями, затем испытайте просмотр, редактирование и удаление под разными ролями. Актуальные требования смотрите в документации конкретного проекта.
Проверили интерфейс, но забыли прямые адреса
Если кнопки «Редактировать» нет, это ещё не доказывает, что действие запрещено. Попробуйте открыть страницу редактирования конкретного материала напрямую под тестовым пользователем. Проверяйте и положительный сценарий, и отказ: кому страница доступна и кому недоступна.
Хорошая роль отвечает на вопрос «какую работу человек выполняет», а не «какому сотруднику нужно срочно открыть эту страницу».
Как выбрать границы доступа
| Подход | Подходит, когда | Цена решения |
|---|---|---|
| Стандартные роли и разрешения ядра | Права отличаются по типам действий и материалов, а разделения по командам не требуется | Схема проста, но не выражает автоматически все бизнес-правила сайта |
| Несколько ролей у пользователя | Сотрудник регулярно совмещает независимые функции | Легче собирать доступы по задачам, но сложнее проверять итоговые права при сочетаниях |
| Дополнительный механизм контроля доступа | Нужно ограничение, которого не дают штатные разрешения, например по отдельному правилу проекта | Появляются зависимость от модуля, требования к совместимости и дополнительные сценарии тестирования |
Практический критерий такой: если нужное правило можно выразить разрешением ядра и оно проходит проверки на чужих материалах, не усложняйте схему. Если доступ зависит от команды, категории, проекта или другого условия, сначала уточните, покрывает ли его конкретное решение. Не обещайте себе, что модуль «просто добавит галочку»: проверьте документацию и поведение на копии сайта.
Что делать дальше
Сохраните матрицу ролей вместе с документацией проекта и назначьте владельца процесса: человека, который согласует новые права и пересматривает старые. При изменении ролей проверяйте тестовые аккаунты, а при обновлении Drupal или модулей повторяйте ключевые сценарии доступа. Следующий полезный шаг — составить набор тестов для опубликованного, неопубликованного и чужого материала каждого важного типа.
Термин: контроль доступа к материалам — набор правил, по которым система решает, может ли пользователь просматривать или менять конкретный материал; он шире, чем наличие кнопки в интерфейсе.
Редактор изображений: Убрать лишнее, заменить фон, добавить объект, расширить кадр — на вашем изображении.
Спросить за 20 ₽Источники: Drupal User Guide: Managing User Accounts, Drupal.org: User Guide
Частые вопросы
Где в Drupal настраиваются права пользователей?
Чем отличаются права редактировать собственные и любые материалы?
Можно ли назначить пользователю несколько ролей?
Почему разрешение включено, а пользователь всё равно не видит нужную страницу?
Нужно ли ставить модуль для управления доступом к материалам?
Эти рекомендации подходят для Drupal 7?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.