RLS
RLS (Row Level Security) - самый детальный уровень доступа. Он позволяет пользователям видеть разные данные в одних и тех же графиках, в зависимости от их учётной записи.
Политика настройки доступа: ограничивающая. Вы указываете пользователей / ГП, которым нужно ограничить доступ.
Например, есть такой простой отчёт по продажам:
И вам нужно сделать, чтобы региональные менеджеры видели только свои продажи, а остальных пользователей не ограничивать.
Для этого мы переходим в менеджер данных и настраиваем нашу модель. При наведении на модель данных в панели нажимаем на иконку настройки доступа:
В первую очередь будет рассмотрен один из вариантов реализации данного функционала. После этого будут разъяснены принципы его работы, а также представлены доступные возможности.
В качестве примера будет использоваться поле «Регион» из справочника «Магазины».
Пример реализации:
Создаём правило и называем его:
После чего открывается окно настройки правила RLS
Блоки Пользователи и Группы отвечают за тех, на кого мы накладываем ограничение на данных.
Блок Переменные позволяет привязать пользователям / ГП их значения для дальнейшего использования в условии отображения отдельных строк данных.
Блок Фильтр – непосредственно описывает правило.
Первым шагом добавляем пользователей, которых мы хотим ограничить в данных: например, региональные менеджеры.
Все прочие пользователи никак не будут ограничены.
Затем создаём переменную manager_regions. Значение по умолчанию – пустая строка .
После чего задаём пользователям их значения. Выбираем moscow_manager и прописываем его регион Москва.
Значения должны с точностью совпадать с теми, что лежат в данных.
Для rostov_manager значение, соответственно, Ростов.
И, наконец, само правило: WHERE shops.region in ( {{manager_regions}} )
Проверим, как работает правило.
Так это выглядит у обычного пользователя, для которого нет правила:
Так это выглядит под пользователем moscow_region:
Видим, что значения всех графиков изменились, в фильтре остался только регион Москва, а рейтинг, помимо фильтрации по Москве, автоматически перешёл на следующий уровень drill_down – сразу до магазинов.
По rostov_manager аналогично:
Как это работает?
На каждый запрос от визуальных компонентов накладывается условие, описанное в правиле
WHERE shops.region in ( {{manager_regions}} )
На основании текущей учётной записи вместо всех переменных подставляются их значения. На примере менеджера Московских магазинов это
WHERE shops.region in ( ‘Москва’ )
Таким образом каждый из перечисленных пользователей будут видеть только свои данные. Все прочие по умолчанию видят все данные.
Какие ещё есть возможности RLS?
В форме настройки правила вы пишете произвольный SQL (язык структурированных запросов), ограничиваясь лишь его синтаксисом и своим воображением. Важно лишь помнить о том, что переменные – это простая подстановка значений, а также о кавычках, когда работаете с текстовыми значениями.
В нашем случае мы сразу заложили логику, когда под управлением одного менеджера может быть несколько регионов, поэтому используется оператор IN. В простом случае можно использовать WHERE shops.region = {{manager_region}}
Разберём несколько вариаций нашей задачи:
- Если в справочнике магазинов уже прописан их менеджер, правило можно описать следующим образом
WHERE shops.manager = {{manager}}, задав предварительно значения переменной для каждого менеджера - Если у вас более сложная иерархия, например менеджеры магазинов и региональные менеджеры
Хорошим вариантом будет создать 2 правила: для обычных менеджеров и для региональных. Их логика схожа с п.1. В этом случае для каждого из них будет работать своё правило.
Также можно описать всё в одном:
- описываем 2 переменные: manager и
region_manager. У обычных менеджеров будет заполнена только первая, у региональных – вторая. Например, у Смирнова (магазин М10)
- фильтр задаём выражением
WHERE manager = '{{manager}}' or region_manager = '{{region_manager}}'
Таким образом, у Смирнова фильтр примет вид:
WHERE manager = 'Смирнов' or region_manager = ''
А т.к. пустых региональных менеджеров в данных нет, он увидит данные только по своему магазину.
Мы разобрали несколько бизнес-кейсов, теперь рассмотрим технические возможности:
- Можно задавать несколько правил на одну и ту же модель данных. Если один пользователь фигурирует в несольких правилах, для него будут применены все ограничения
- Правила можно экспортировать/импортировать в csv/xlsx. Помогает переносить логику между проектами
У разработчиков проекта есть возможность тестировать работу RLS, не запрашивая доступы пользователей и не создавая тестовые УЗ. Для этого предусмотрен предпросмотр RLS – просто включите его в настройках проекта и выберите пользователя, под которым хотите проверить работу правил.
Это сильно сократит время отладки. В целях безопасности предпросмотр RLS работает только для администраторов, а также разработчиков, не ограниченных настроенными правилами.