Простейший пример работы с RLS

18 декабря 2012

Файлы для загрузки:

Демобаза с примером из статьи

Предисловие

RLSЧто такое RLS? RLS (Row Level Security) - ограничение на уровне записей в таблицах базы данных. В отличии от разграничения прав на основе использования ролей, которые фактически разграничивают доступ к отдельным таблицам базы целиком, RLS позволяет настраивать доступ к отдельным записям.

Рассмотрим простейший пример, в котором решим одну из самых распространенных задач разграничения прав доступа. Предположим, что руководство поставила перед программистом задачу разграничить видимость записей справочника "Контрагенты" по пользователям. Главный критерий разделения прав - "Менеджер по закупкам" может видеть только поставщиков, а "Менеджер по продажам" только клиентов. Если контрагент является и клиентом, и поставщиком, то любой из названных пользователей может работать с этим элементом.

Что имеем?

В нашей базе зарегистрировано три пользователя, каждый из которых имеет соответствующие ему права, настроенные с помощью ролей (см. след. скриншот).

Права и пользователи

В соответствии с задачей нам необходимо разграничить доступ для пользователей на справочник "Контрагенты". В справочник добавлены два реквизита "Клиент" и "Поставщик" с типом "булево". Реквизиты будут указывать тип отношений контрагента к нашей организации.

Справочник "Контрагенты"Соответственно, пользователи с ролью "МенеджерПоЗакупкам" будут видеть те записи, для которых установлен флажок "Поставщик", а роль "МенеджерПоПродажам" откроет доступ к элементам с флагом "Клиент". Все элементы будут видеть пользователи, у которых доступна роль "ПолныеПрава" или обе названных выше роли.

Пример простейший, но если вы сталкиваетесь с разграничением доступа на записи впервые, то могут возникнуть трудности с реализацией самой RLS, поскольку новички попросту не знают как выполнить настройку.

Как задействовать RLS в ролях?

Рассмотрим механизм RLS на созданной роли "МенеджерПоПродажам". В роли настроен доступ на все действия над справочником "Контрагенты", кроме действий любого вида удаления (интерактивного и программного). Настройку прав для объекта можно посмотреть на следующем скриншоте.Настройки ограничений

Если вы обратили внимание, то для таких прав как "Чтение", "Добавление" и "Изменение" строки выделены серым цветом и отмечены специальными пиктограммами справа. Эти обозначения показывают, что для данных прав используется механизм ограничения прав на уровне записей.

Принцип работы RLS для ролей заключается в добавлении к правам (чтение, добавление, изменение или удаление) специальных условий, которые должны указать системе при построении запросов к СУБД, какие записи необходимо выбирать. Фактически, текст из описания ограничения доступа будет добавлен платформой автоматически для любых запросов к базе в секцию "ГДЕ". Чтобы лучше понять выше сказанное, обратимся к нашему примеру.

Поскольку мы будем ориентироваться на реквизиты справочника "Контрагенты" - "Клиент" и "Поставщик", то в соответствующих ролях для прав чтения, добавления и изменения установим ограничение доступа: "Контрагенты ГДЕ Контрагенты.[ИМЯ РЕКВИЗИТА]'". В результате мы получим следующие ограничения (см. след. скриншот).Ограничение доступа

Как мы видим, текст условия ограничения получился очень простым. Однако на практике текст описания ограничения доступа на уровне записей может содержать в себе сложные условия на языке запросов, синтаксис также поддерживает передачу параметров из параметров сеансов и функциональных опций. Но для нашего просто примера этого достаточно. Ниже приведу текст ограничений доступа на записи из типовой конфигурации УПП для справочника "Организации" (см. след. скриншот).

Ограничения доступа

А теперь смотрим результат!

Посмотрим как внесенные изменения повлияли на работу в режиме предприятия. Дополнительно проанализируем изменение запросов к СУБД с применением RLS.

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

Контрагенты

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

Контрагенты

Интересно то, что запись "ООО 'Мясгаз'" доступна обоим пользователям. Обусловлено это тем, что контрагент является и клиентом, и поставщиком. Интересной особенностью здесь будет являться то, что если мы сбросим у этой записи флаг "Клиент" под пользователем "Менеджер по продажам", то при записи контрагента появится ошибка (см. след. скриншот).

Контрагенты

Все потому, что записываемый элемент больше не удовлетворяет нашему условию в поле "Ограничение доступа" роли "МенеджерПоПродажам" и поэтому не может быть записан.

Теперь перейдем к рассмотрению запроса к базе данных на языке SQL. Если мы откроем форму списка контрагентов под полными правами, то RLS не будет задействован и мы получим чистый запрос. Если зайдем в режим предприятия, например, под пользователем "Менеджер по закупкам", то запрос уже будет изменен в соответствии с условиями ограничения на уровне записей. Далее приведен скриншот со сравнением получившихся запросов.

Контрагенты

Как мы видим, механизм RLS добавляет дополнительные условия в SQL-запросы, чтобы ограничить выборку по условию, описанному в поле "Ограничение доступа" для выбранного права в роли.

То, что система ставит в запросы дополнительные условия выборки позволяет придти к выводу, что сложные условия ограничения доступа на уровне записей увеличивают нагрузку на сервер СУБД, поэтому нужно быть аккуратным при их использовании.

На этом простейший пример по использованию механизма RLS закончен. В последующих статьях рассмотрим другие его интересные возможности.

Удачных экспериментов и спасибо за интерес к материалу!



comments powered by Disqus