Права доступа
Как доступ к бэк-офису контролируется ролями и организациями.
Введение
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 шага вручную, не выходя оттуда:
- Создать пользователя Netuno (
netuno_user) с выбранными именем пользователя/паролем. - Создать Персону, связав её с этим пользователем Netuno.
- В
Организация > Участникисвязать эту Персону с организацией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 — это два отдельных списка, один во фронтенде, другой в бэкенде. При добавлении нового защищённого сервиса необходимо обновить оба; изменение только сервера скрывает ошибку (меню продолжает показывать опцию, которая на практике будет запрещена), а изменение только меню ничего не защищает на самом деле.
Как защитить новый сервис
- Создайте сервис как обычно в
server/services/. - Добавьте путь сервиса (
path/method) в правильный список вserver/core/_service_config.js—CONTENT_MANAGEMENT_PATHS,SITE_ADMIN_PATHSилиACCESS_MANAGEMENT_PATHS— в зависимости от того, кто должен иметь к нему доступ. Если он публичный, добавьте вPUBLIC_PATHS. - Если у сервиса есть соответствующий пункт в меню Закрытой области, также обновите
SideMenu, чтобы фильтр соответствовал реальным разрешениям.