Перейти к основному содержимому

Права доступа

Как доступ к бэк-офису контролируется ролями и организациями.

Введение​

CLUAR контролирует доступ к бэк-офису через роли (группы), назначенные людям внутри организации. Каждый REST-сервис сервера классифицируется по категории доступа, и только тот, у кого есть нужная роль в нужной организации, может его использовать.

Роли​

Существует 5 предварительно созданных ролей (user_group):

КодНазвание
administratorАдминистратор
editorРедактор
authorАвтор
contributorУчастник
subscriberПодписчик
Не всем ролям пока назначены разрешения

На сегодняшний день только Администратор и Редактор действительно имеют доступ к чему-либо — это единственные роли, упомянутые в правилах доступа (см. ниже). Автор, Участник и Подписчик уже существуют как опции в форме, но пока не имеют настроенного доступа; назначение одной из этих ролей кому-либо сегодня не даёт доступа ни к чему в бэк-офисе.

Организация​

Человек имеет роль только в контексте организации — связь создаётся в Организация > Участники (organization_people), связывая Персону + Организацию + Роль.

На сегодняшний день существует только одна организация с кодом admins, и именно в ней проверяются все разрешения. Сущность organization поддерживает иерархию (parent_id, "родительские" организации), но эта иерархия пока не используется в текущих правилах разрешений — все проверки указывают непосредственно на организацию admins.

Первый доступ к режиму редактирования​

CLUAR различает два разных места, где выполняется вход:

  • Бэк-офис Netuno (порт 9000 в среде разработки) — здесь напрямую управляют пользователями Netuno (netuno_user, пара имя пользователя/пароль) и всеми сущностями, включая Персону и Роли.
  • Закрытая область самого веб-сайта (/login, порт 3000 в среде разработки) — сюда редактор контента заходит повседневно, чтобы получить доступ к режиму редактирования страниц.

Чтобы войти в Закрытую область и получить доступ к режиму редактирования, нужен пользователь Netuno с логином, связанный с Персоной, привязанной к организации admins с ролью Администратор или Редактор (см. Организация выше).

Пользователь по умолчанию​

server/setup/030-people.js в CLUAR уже по умолчанию создаёт Персону "admin", связанную с пользователем Netuno с id: 2, а server/setup/050-organization_people.js уже связывает эту Персону с организацией admins с ролью Администратор — то есть этот пользователь сразу рождается с полным доступом.

Логин этого пользователя по умолчанию:

пользователь: admin
пароль: admin

С этими учётными данными можно сразу войти в Закрытую область (/login) как Администратор — без необходимости выполнять какие-либо дополнительные шаги в бэк-офисе Netuno.

Измените пароль по умолчанию в продакшене

admin/admin — это известные и предсказуемые учётные данные. Перед запуском сайта в продакшен измените пароль этого пользователя (или создайте нового Администратора и отключите этого).

Создание новых пользователей​

Существует два возможных пути:

Через Закрытую область (рекомендуется): в Пользователи > Создать пользователя одна форма запрашивает имя, имя пользователя, пароль, e-mail, Организацию и Роль — и создаёт всё сразу: пользователя Netuno, Персону (уже связанную с этим пользователем) и привязку к выбранной организации/роли. Не нужно заходить в бэк-офис Netuno.

Только через бэк-офис Netuno: поскольку бэк-офис даёт прямой доступ ко всем сущностям, можно также выполнить те же 3 шага вручную, не выходя оттуда:

  1. Создать пользователя Netuno (netuno_user) с выбранными именем пользователя/паролем.
  2. Создать Персону, связав её с этим пользователем Netuno.
  3. В Организация > Участники связать эту Персону с организацией admins с ролью Администратор или Редактор.

В обоих случаях созданный человек уже может войти в /login и получить доступ к режиму редактирования.

Как применяются разрешения​

Каждый сервис сервера классифицируется по одной из этих категорий, определённых в server/core/_service_config.js:

КатегорияКто имеет доступПримеры
ПубличныеЛюбой человек, без входаКонтакты, аватар, вход
Управление контентомАдминистратор + РедакторСтраницы, версии, компоненты, словарь, действия
Администрирование сайтаТолько АдминистраторНастройки, языки, синхронизация
Управление доступомТолько АдминистраторОрганизации, персоны, пользователи

Любой сервис, не указанный ни в одной из этих категорий, запрещён по умолчанию — это осознанное решение в коде (явно прокомментированное в файле), чтобы забыть классифицировать новый сервис приводило к блокировке, а не к свободному доступу по недосмотру.

Разрешения не применяются в среде разработки

В среде dev файл _service_config.js освобождает все сервисы в самом начале, до какой-либо проверки — то есть разрешения действительно применяются только в продакшене/staging. При локальном тестировании любой авторизованный пользователь имеет доступ ко всему, независимо от роли.

Интерфейс: меню также фильтруется по разрешениям​

Помимо блокировки на сервере, боковое меню Закрытой области (website/src/components/SideMenu) также фильтрует видимые элементы в соответствии с ролью авторизованного человека — чтобы не показывать опции, которые он не имеет права использовать.

Поддерживайте оба списка синхронизированными

Список "кто что может видеть" в SideMenu поддерживается вручную в соответствии с CONTENT_MANAGEMENT_PATHS, SITE_ADMIN_PATHS и ACCESS_MANAGEMENT_PATHS из _service_config.js — это два отдельных списка, один во фронтенде, другой в бэкенде. При добавлении нового защищённого сервиса необходимо обновить оба; изменение только сервера скрывает ошибку (меню продолжает показывать опцию, которая на практике будет запрещена), а изменение только меню ничего не защищает на самом деле.

Как защитить новый сервис​

  1. Создайте сервис как обычно в server/services/.
  2. Добавьте путь сервиса (path/method) в правильный список в server/core/_service_config.js — CONTENT_MANAGEMENT_PATHS, SITE_ADMIN_PATHS или ACCESS_MANAGEMENT_PATHS — в зависимости от того, кто должен иметь к нему доступ. Если он публичный, добавьте в PUBLIC_PATHS.
  3. Если у сервиса есть соответствующий пункт в меню Закрытой области, также обновите SideMenu, чтобы фильтр соответствовал реальным разрешениям.