Записная книжка программиста. Бухучет инфо Ограничение рлс

Объект конфигурации «роль» дает набор прав на операции (действия) над объектами конфигурации.

Роль «Полные права».

Это всего лишь роль (не предопределенная), в которой установлены флажки на все виды прав на все объекты конфигурации.

Отличие ее от остальных ролей – наличие права «Администрирование».

В случае создания хотя бы одного пользователя, система начинает проверять наличие права «Администрирование» — оно должно быть минимум у одного пользователя.

Ограничение доступа на уровне записей

Row Level Security (RLS) – ограничение на уровне записей.

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

• роли,
• параметры сеанса,
• функциональные опции,
• привилегированные общие модули,
• ключевое слово РАЗРЕШЕННЫЕ в языке запросов.

Механизм предназначен для ограничения доступа к записям таблицы объектов метаданных по произвольным условиям, накладываемым на значения полей строк этих таблиц. Например, чтобы видеть записи только по «своим» контрагентам, организациям и т.д.

Техническая реализация ограничений доступа в 1С

1С формирует запрос к СУБД. Кластер серверов добавляет к запросу секцию ГДЕ, в которой содержится текст условия на ограничение доступа по RLS, затем этот запрос отправляется в СУБД, извлеченные данные возвращаются на клиент 1С.

Такой механизм будет работать при любом запросе из клиента:

• в отчетах,
• в динамических списках и в обычных формах списков
• в произвольных запросах.

Подобная реализация механизма сильно влияет на производительность.

Пути обхода ограничений доступа.

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

А) Привилегированный модуль — это общий модуль с флагом «Привилегированный» в свойствах.

Его особенность заключается в том, что код в нем исполняется без какого-либо контроля прав доступа, в том числе и RLS.

Б) Также привилегированный режим можно включить для модулей объектов документов . Это делается в свойствах документа, флаг

• Привилегированный режим при проведении
• Привилегированный режим при отмене проведения

В) Метод УстановитьПривилегированныйРежим()

Системная команда, позволяет сделать часть кода любого модуля привилегированной.

Со следующей строки кода будет действовать привилегированный режим исполнения.

Действовать он будет до строки отключения этого режима или до конца процедуры / функции

(Истина );

// любой код тут будет исполнен без контроля прав и RLS

УстановитьПривилегированныйРежим (Ложь ); // либо конец процедуры / функции

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

Если в процедуре или функции вызовов метода УстановитьПривилегированныйРежим (Ложь ) сделано больше, чем вызовов метода УстановитьПривилегированныйРежим (Истина ), то будет вызвано исключение

Функция ПривилегированныйРежим () возвращает Истина , если привилегированный режим еще включен, и Ложь , если он полностью выключен. При этом не анализируется количество установок привилегированного режима в конкретной функции.

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

Также существует возможность стартовать привилегированный сеанс. Это сеанс, в котором привилегированный режим установлен с самого начала работы системы. При этом во время работы метод ПривилегированныйРежим () будет всегда возвращать Истина , а возможность отключить привилегированный режим не поддерживается. Стартовать привилегированный сеанс может только пользователь, которому доступны административные права (право Администрирование). Запуск сеанса можно выполнить с помощью ключа командной строки запуска клиентского приложения UsePrivilegedMode или параметра строки соединения с информационной базой prmod .

Закономерно возникает вопрос: Зачем тогда вообще настраивать ограничения доступа, если его можно так легко обойти?

Безопасный режим.

Да, можно написать внешнюю обработку с привилегированным режимом исполнения и выгрузить / испортить данные. Для предотвращения этого в системе есть метод глобального контекста

УстановитьБезопасныйРежим ().

Безопасный режим кроме прочего игнорирует привилегированный режим.

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

При выполнении запрещенных операций во время выполнения генерирует исключение.

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

Настройка ограничения доступа

RLS можно настроить только для прав:

• чтение (select)
• добавление (insert)
• изменение (update)
• удаление (delete)

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

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

Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан).

Для всех остальных прав такой возможности нет.

Добавим новое ограничение для права «чтение» справочника «Номенклатура». Откроется список полей, для которых можно настроить добавляемое ограничение.

Это означает, что при попытке получить доступ к отмеченным флажками полям, ограничение сработает, а при попытке получить доступ к неотмеченным полям ограничение не сработает.

Если выбрать флаг «Прочие поля », ограничение будет настроено для всех полей таблицы, кроме полей, для которых ограничения заданы явным образом.

*Особенность: для прав добавление, изменение, удаление:

• Ограничение может быть настроено только для всех полей.
• Ограничение может быть только одно.

Для права «Чтение» можно настроить несколько условий, они будут объединяться логическим оператором «И».

В ограничениях на объекты базы данных следующих типов могут быть использованы не все поля основного объекта данных ограничения:

• в регистрах накопления ограничения доступа могут содержать только измерения основного объекта ограничения;
• в регистрах бухгалтерии в ограничениях можно использовать только балансовые измерения основного объекта ограничения

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

Механизм наложения ограничений доступа.

Любая операция над данными, хранимыми в базе данных, в «1С:Предприятии» в конечном счете приводит к обращению к базе данных с некоторым запросом на чтение или изменение данных. В процессе исполнения запросов к базе данных внутренние механизмы «1С:Предприятия» выполняют наложение ограничений доступа. При этом:

• Формируется список прав (чтение, добавление, изменение, удаление), список таблиц базы данных и список полей, используемых этим запросом.
• Из всех ролей текущего пользователя выбираются ограничения доступа к данным для всех прав, таблиц и полей, задействованных в запросе. При этом если какая-нибудь роль не содержит ограничений доступа к данным какой-нибудь таблицы или поля, то это значит, что в данной таблице доступны значения требуемых полей из любой записи. Иначе говоря, отсутствие ограничения доступа к данным означает наличие ограничения ГДЕ Истина .
• Получаются текущие значения всех параметров сеанса и функциональных опций , участвующих в выбранных ограничениях.

Для получения значения параметра сеанса или функциональной опции от текущего пользователя не требуется наличие права на получение этого значения. Однако если значение некоторого параметра сеанса не было установлено, то произойдет ошибка и запрос к базе данных выполнен не будет.

Ограничения, полученные из одной роли, объединяются операцией И .

Ограничения, полученные из разных ролей, объединяются операцией ИЛИ .

Построенные условия добавляются к SQL-запросам, с которыми «1С: Предприятие» обращается к СУБД. При обращении к данным со стороны условий ограничения доступа проверка прав не выполняется (ни к объектам метаданных, ни к объектам базы данных). Причем механизм добавления условий зависит от выбранного способа действия ограничений «все» или «разрешенные».

*Особенность : Если пользователю доступны несколько ролей с настроенными ограничениями на уровне записей к одному объекту, то в этом случае условия ограничений складываются логической операцией «ИЛИ ». Другими словами полномочия пользователя складываются.

Отсюда вытекает след вывод: не допускать пересечения условия ограничения доступа к одному объекту в разных ролях, т.к в этом случае сильно усложнится текст запроса и это повлияет на производительность.

Способ «Все».

При наложении ограничений способом «все» к SQL-запросам добавляются условия и поля так, чтобы «1С:Предприятие» могло получить информацию о том, были ли в процессе исполнения запроса к базе данных использованы данные, запрещенные для данного пользователя или нет. Если запрещенные данные были использованы, то инициируется аварийное завершение запроса из-за нарушения прав доступа.

Наложение ограничений доступа способом «все» схематически представлено на рисунке:

Способ «Разрешенные».

При наложении ограничений способом «разрешенные» к SQL-запросам добавляются такие условия, чтобы запрещенные текущему пользователю записи не оказывали влияния на результат запроса. Иначе говоря, при наложении ограничений в режиме «разрешенные» запрещенные данному пользователю записи считаются отсутствующими и на результат операции не влияют, что схематически представлено на рисунке:

Ограничения доступа к данным накладываются на объекты базы данных в момент обращения «1С:Предприятия» к базе данных.

В клиент-серверном варианте «1С:Предприятия» наложение ограничений выполняется на сервере «1С:Предприятия».

Однако эта опция (РАЗРЕШЕННЫЕ) не сработает в случае, если мы в запросе обратимся к таблице, для которой не настроены ограничения доступа, но в которой есть ссылки на строки таблицы с настроенными ограничениями. В этом случае результат запроса выдаст «<Объект не найден>…...» вместо значения ссылочного поля.

Если вы разрабатываете отчет или обработку с использованием запросов типовой или самописной конфигурации, всегда ставьте флаг «Разрешенные» , чтобы отчет работал под любым пользователем с любым набором прав.

В случае объектного чтения данных из базы нет возможности поставить флаг «Разрешенные». Поэтому нужно настраивать отборы для объектного чтения с учетом возможных ограничений прав доступа для пользователя. Средств получения только разрешенных данных в объектной технике не предусмотрено.

Важно, что если в запросе не указано ключевое слово РАЗРЕШЕННЫЕ, то все отборы, заданные в этом запросе, не должны противоречить ни одному из ограничений на чтение объектов базы данных, используемых в запросе. При этом если в запросе используются виртуальные таблицы, то соответствующие отборы должны быть наложены и на сами виртуальные таблицы.

Практика 1. Конструктор запросов в настройках RLS.

Составим текст секции «ГДЕ» в запросе к справочнику. Можно воспользоваться конструктором запросов.
Конструктор имеет урезанный вид.

Закладка «Таблицы»

Основная таблица будет таблицей объекта, для которого настраивается ограничение.

Можно также выбирать и другие таблицы и настраивать между ними различные связи на закладке «Связи».

Закладка «Условия»

Здесь настраиваются собственно условия ограничения доступа

Добавим условия на реквизит «Цена» справочника номенклатура для права на «чтение» ко всем полям таблицы.

«Номенклатура ГДЕ Номенклатура.Цена > 500»

Проверим, как сработает это простое правило. Таблица справочника содержит такие элементы:

После настройки ограничения доступа таблица покажет только элементы, удовлетворяющие условию:

Пропали также и группы. Изменим текст ограничения

«Номенклатура ГДЕ Номенклатура.Цена > 500

ИЛИ Номенклатура.ЭтоГруппа»

Ну вот теперь то, что нужно.

Если в настройке списка убрать отображение поля «код», будут выведены все элементы справочника, т.е. ограничение не сработало. Если поставить отображение поля «Код», ограничение будет работать.

При этом, несмотря на то, что элемент справочника виден в поле списка, его форму нельзя будет открыть, потому что настроено ограничение на реквизит. То же самое в произвольном запросе: при попытке получить «ограниченный» реквизит, будет ошибка доступа.

Если попытаться получить «ограниченный» реквизит программным образом, также будет вызвана ошибка доступа.

Более того, нельзя будет обратиться к любым полям объекта через ссылку, т.к при получении ссылки система считывает весь объект целиком, и если в нем есть «ограниченные» реквизиты, объект считан не будет.

Поэтому при программной работе с объектами БД нужно иметь в виду возможные ограничения на уровне записей и получать все нужные данные объекта запросом и затем помещать их в структуру или исполнять часть кода в привилегированном модуле.

После настройки ограничения доступа изменилось отображение строки в списке прав – она стала серой и появилась пиктограмма.

Ограничения при настройке доступа (RLS).

• Нет секции Итоги;
• Нельзя обращаться к виртуальным таблицам регистров;
• В явном виде нельзя использовать параметры;
• Во вложенных запросах могут использоваться любые>/span> средства языка запросов, кроме :
  • оператора В ИЕРАРХИИ;
  • предложения ИТОГИ;
  • результаты вложенных запросов не должны содержать табличные части>/span>;
  • виртуальных таблиц , в частности ОстаткиИОбороты

Практика 2. Номенклатура с актуальной ценой.

Сделать ограничение доступа, если нужно выводить номенклатуру с актуальной ценой больше определенного значения, например, 100.

Решение:

Добавляем новое правило ограничения доступа для справочника «Номенклатура» на право «чтение».
Выбираем «прочие поля».
В конструкторе добавляем вложенный запрос. В нем выбираем таблицу регистра сведений «Цены номенклатуры».
Вкладки «порядок» нет – это особенность конструктора запросов для построения запроса ограничения доступа.
На вкладке «Дополнительно» ставим «первые 999999999», вкладка «порядок» появилась.
Настраиваем упорядочивание по полю «Период» по убыванию.
Затем настраиваем связь основной таблицы с вложенным запросом по ссылке.

Шаблоны ограничений доступа .

Практика 3. Ограничение на «контрагенты» по значению в константе.

Настроим ограничение доступа для справочника Контрагенты по значению, которое хранится в Константе.

Кроме этого, нужно настроить ограничение и для всех объектов, использующих справочник «Контрагенты» в реквизитах.

Решение

Для справочника «Контрагенты» для права «чтение» настроим ограничение, добавив в секцию «Условия» вложенный запрос к константе. Не забыть ЭтоГруппа.

Видим проблему, справочник Контрагенты фильтруется верно, а документы с реквизитом «Контрагент» отображаются все, некоторые с «битыми» ссылками в реквизите «Контрагент».

Теперь нужно настроить ограничение доступа для всех объектов, использующих ссылку на «Контрагенты». Найдем их сервисом «поиск ссылок на объект».

Скопируем и немного доработаем текст условия RLS из справочника «Контрагенты». Это нужно сделать столько раз, сколько найдено объектов.

Или использовать шаблон ограничений доступа, чтобы избежать проблем дублирования кода.

Шаблоны ограничений доступа настраиваются на уровне роли и могут использоваться для любого объекта в рамках редактируемой роли.

Можно вынести в шаблон любой кусок текста ограничения доступа. Вызов шаблона осуществляется через символ «#». Например, #ШаблонКонтрагент.

Через # в 1С пишутся инструкции препроцессору. В контексте исполнения настроек ограничений доступа платформа заменяет текст вызова шаблона на текст шаблона.

Вынесем в шаблон «ШаблонКонтрагент» текст после слова ГДЕ, кроме текста про ЭтоГруппа.

Параметры в шаблонах ограничений доступа.

Продолжим решение задачи 2.

Проблема заключается теперь в том, что основная таблица в справочнике называется «контрагент», в документе «Приходная накладная». Проверяемое поле в справочнике называется «ссылка», в документе – «Контрагент».

Изменим в тексте шаблона название основной таблицы на «#ТекущаяТаблица»

«#ТекущаяТаблица» — это предопределенный параметр.

И через точку укажем номер входного параметра – «.#Параметр(1)

«#Параметр» — это тоже предопределенное значение. Может содержать произвольное количество входных параметров. Обращение к ним происходит по порядковому номеру.

В тексте ограничения доступа для справочника укажем следующее:

Для документа следующее:

«РеализацияТоваров ГДЕ #ШаблонКонтрагент(«Контрагент»)»

При вызове шаблона ограничения доступа параметры в него передавать нужно только как Строка, т.е в кавычках.

Основная таблица — Номенклатура

Текст шаблона такой:

#ТекущаяТаблица ГДЕ #ТекущаяТаблица.#Параметр(1) = #Параметр(2)

Текст шаблона содержит часть текста на языке ограничения доступа к данным и может содержать параметры, которые выделяются при помощи символа «#» .

После символа «#» могут следовать:

• Одно из ключевых слов:
  • Параметр, после которого в скобках указывается номер параметра в шаблоне;
  • ТекущаяТаблица – обозначает вставку в текст полного имени таблицы, для которой строится ограничение;
  • ИмяТекущейТаблицы – обозначает вставку в текст полного имени таблицы (как строковое значение, в кавычках), к которой применяется инструкция, на текущем варианте встроенного языка;
  • ИмяТекущегоПраваДоступа – содержит имя права, для которого выполняется текущее ограничение: ЧТЕНИЕ/READ, ДОБАВЛЕНИЕ/INSERT, ИЗМЕНЕНИЕ/UPDATE, УДАЛЕНИЕ/DELETE;
• имя параметра шаблона – означает вставку в текст ограничения соответствующего параметра шаблона;
• символ «#» – обозначает вставку в текст одного символа «#» .

В выражении ограничения доступа могут содержаться:

• Шаблон ограничения доступа, который указывается в формате #ИмяШаблона(«Значение параметра шаблона 1», «Значение параметра шаблона 2»,...) . Каждый параметр шаблона заключается в двойные кавычки. При необходимости указания в тексте параметра символа двойной кавычки следует использовать две двойные кавычки.
• Функция СтрСодержит(ГдеИщем, ЧтоИщем) . Функция предназначена для поиска вхождения строки ЧтоИщем в строке ГдеИщем. Возвращает Истина в случае, если вхождение обнаружено и Ложь – в противном случае.
• Оператор + для конкатенации строк.

Для удобства редактирования текста шаблона на закладке Шаблоны ограничений в форме роли нужно нажать кнопку Установить текст шаблона. В открывшемся диалоге ввести текст шаблона и нажать кнопку ОК.

Их нельзя установить методом УстановитьПараметр() или чем-то подобным.

В качестве параметров в данном случае выступают:

• Параметры сеанса
• Функциональные опции

Чтение параметров сеанса в запросе ограничения доступа происходит в привилегированном режиме, т.е без контроля прав на операции с ними.

Практика 4. Доступ к «своим» контрагентам

Необходимо настроить ограничение доступа текущего пользователя к «своим» контрагентам.

Есть справочник «Пользователи», справочник «Контрагенты», документы с реквизитом «Контрагент».

Текущий пользователь должен видеть данные только по тем контрагентам, для которых с ним установлена связь.

Связь тоже нужно настроить.

Возможные варианты:

Установления связей пользователь + контрагент

• Реквизит в справочнике контрагенты
• Регистр сведений

Возможные решения задачи:

• Хранить пользователя в константе – плохой вариант, константа доступна всем пользователям.
• Хранить в параметрах сеанса фиксированный массив контрагентов текущего пользователя – не очень хороший вариант, контрагентов может быть много
• Хранить в параметрах сеанса текущего пользователя, затем запросом получать список «его» контрагентов – приемлемый вариант.
• Другие варианты.

Решение.

Создадим новый параметр сеанса «ТекущийПользователь» и пропишем его заполнение в модуле сеанса.

Создадим регистр сведений «Соответствие менеджеров и контрагентов»

Создадим новую роль и в ней новое ограничение доступа для документа «ПриходнаяНакладная».

В тексте запроса соединим основную таблицу с регистром сведений по Контрагент = Контрагент и Менеджер = &ТекущийПользователь. Вид соединения Внутреннее.

По возможности лучше избегать вложенных запросов в текстах ограничения доступа, т.к он будет выполняться при каждом чтении данных из этого объекта из БД.

Проверяем – ограничения работают

*Особенность : Если изменить список контрагентов пользователя в регистре ограничения доступа будут действовать сразу без перезапуска сеанса пользователя.

Практика 5. Дата запрета изменений.

Необходимо реализовать ограничение на редактирование данных раньше установленной даты запрета изменений.
Ограничивать нужно для пользователей.

Создадим регистр сведений «ДатыЗапретаИзменений» с измерением Пользователь, ресурс ДатаЗапрета.

Построим логику решения таким образом:

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

Очевидно, что такое ограничение можно настроить для объектов базы данных, которые имеют некоторую позицию на оси времени. Это могут быть

• Документы
• Периодические регистры сведений

Создадим новую роль «ОраниченияПоДатеЗапретаИзменений».

В ней для документа «ПриходнаяНакладная» для права «изменение» добавим новое ограничение доступа.

Настройку указываем для всех полей.

Текст ограничения такой:

ПриходнаяНакладная ИЗ Документ.ПриходнаяНакладная КАК ПриходнаяНакладная

ДатыЗапретаИзменений.ДатаЗапрета КАК ДатаЗапрета
ИЗ

ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
МАКСИМУМ(ДатыЗапретаИзменений.Пользователь) КАК Пользователь
ИЗ
РегистрСведений.ДатыЗапретаИзменений КАК ДатыЗапретаИзменений
ГДЕ
(ДатыЗапретаИзменений.Пользователь = &ТекущийПользователь
ИЛИ ДатыЗапретаИзменений.Пользователь = ЗНАЧЕНИЕ(Справочник.пользователи.ПустаяСсылка))) КАК ВЗ_Пользователь
ПО ДатыЗапретаИзменений.Пользователь = ВЗ_Пользователь.Пользователь) КАК ВложенныйЗапрос
ПО ПриходнаяНакладная.Дата > ВложенныйЗапрос.ДатаЗапрета

Проверяем – ограничение работает.

Использование инструкций препроцессору

#Если Условие1 #Тогда

Фрагмент запроса 1

#ИначеЕсли Условие2 #Тогда

Фрагмент запроса 2

#Иначе

Фрагмент запроса 3

#КонецЕсли

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

Такой подход в контексте построения ограничений доступа удобен тем, что в зависимости от условий будет скомпилирован более короткий текст запроса. А более простой запрос меньше нагружает систему.

Минус заключается в том, что конструктор запроса с таким текстом работать не будет.

*Особенность :

В отличие от инструкций препроцессору встроенного языка в текстах ограничения доступа перед оператором Тогда нужно ставить решетку — #Тогда

Практика 6. Переключатель «Использовать RLS»

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

Для этого добавим Константу и параметр сеанса с именем «ИспользоватьRLS».

Пропишем в Модуле сеанса установку значения параметра сеанса из значения константы.

Добавим во все тексты ограничения доступа такой код:

«#Если &ИспользоватьRLS #Тогда ….. #КонецЕсли»

Проверяем – все работает.

Однако, теперь после включения флага «использовать РЛС» изменения сразу в силу не вступят. Почему?

Потому что параметр сеанса устанавливается при запуске сеанса.

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

Конец первой части.

В системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).

Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.

1С RLS (Record Level Security) или ограничение прав на уровне записи — это прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.

Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).

Основное преимущество — наличие механизма вообще, механизм достаточно сложный и интересный. Позволяет очень тонко разграничить права пользователей — пользователи могут даже не догадываться о существовании в системе других данных.

Недостатки 1С 8 RLS

Среди недостатков можно отметить заметное падение производительности системы. Это вызвано тем, что платформа при построении запроса в базе данных осложняет любой запрос разработчика дополнительными условиями.

Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.

Настройка ограничения прав на уровне записей 1С RLS

Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:

• Чтение
• Добавление
• Изменение
• Удаление

Получите 267 видеоуроков по 1С бесплатно:

Внешне настройка RLS (прав на уровне записей) похожа на составление простого . Пример шаблона для ограничения доступа видимости документов по клиенту из шапки документа:

##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда

ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли

По сути, этот запрос каждый раз добавляется при запросе к таблице «#ТекущаяТаблица». Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.

Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — « «. Как правило, они задаются при старте сессии пользователя.

Конструктор ограничения доступа к данным

Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:

В совете приведена пошаговая инструкция для настройки Record Level Sceurity (RLS) в Аксапте 3.0.

Где об этом написано в Документации

Русская версия: Users Guide for Admin (Russian)_3.0.pdf (стр.126)
Английская версия: User"s Guide for Administration (стр. 40, 101)

Введение

Ограничение прав на уровне записей (Record Level Security - RLS) позволет ограничить доступ к записям разным группам пользователей. Например, одна группа менеджеров может видеть российских клиентов, а другая - зарубежных. Причем менеджеры, работающие с российскими клиентами не должны видеть зарубежных клиентов. Мало того, менеджеры даже видеть их не должны.

RLS в Аксапте работает совместно с системой настройки обычных прав. Это значит, что для того, чтобы ограничить доступ к тому или иному полю таблицы, необходимо настроить обычные права на эти таблицу. Задача RLS - незаметно для пользователя отфильтровать записи.

Настройка ограничения прав на уровне записей сводится к определению фильтров на те или иные таблицы для разных групп пользователей. Если пользователь входит в несколько групп, то фильтры объединяются по условию ИЛИ.

Искусство настройки прав доступа состоит в том, чтобы правильно определить фильтры на правильные таблицы. Причем сделать это оптимальным образом, чтобы не снизить производительность системы.

Настройка

Перед тем, как будем выполнять настройку ограничения прав доступа необходимо сделать предварительные шаги:

Подготовительная работа завершена. Сейчас пользователь Тест не имеет никаких прав. Можно зайти в Аксапту под пользователем тест и убедится, что у него не получается открыть даже главное меню.

Можно приступать к настройке RLS:

1. Настроим обычные права для группы тстГруппа1.

Теперь настроим RLS

Для созданной настройки отредактируйте запрос.

• Нажмите на кнопку Запрос;

Собственно говоря, все! RLS настроен. Сейчас пользователь Тест получил права на чтение данных из модуля Расчеты с клиентами и право на создание и удаление заказов. Кроме того, на таблицу клиентов наложен фильтр. Начиная с этого момента, пользователи, принадлежащие группе тстГруппа1, смогут увидеть только прочих клиентов (клиентов, для которых установлена группа Прочие).

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

Зайдите в Аксапту под пользователем Тест. Откройте список клиентов (Главное меню \ Расчеты с клиентами \ Клиенты). Убедитесь, что список клиентов отображает только тех клиентов, для которых установлена группа с кодом Прч.

Обратите внимание, что в главном меню открылась не только закладка Расчеты с клиентами. Открылась также закладки Главная книга, Денежные средства, CRM, Управление запасами, Основное. Дело в том, что дав права на модуль клиентов, мы затронули множество таблиц из других модулей. Да, конечно, ненужные закладки почти пустые. Но все равно, в реальной жизни права надо давать намного аккуратнее.

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

Попробуйте наложить фильтр "*" на группу (Установите мышку на колонку Группа клиентов, нажмите правую кнопку, выберите пункт Найти..., введите фильтр "*").

Попробуйте также наложить фильтр "!Прч". Попробуйте наложить фильтры на другие поля. Убедитесь, что фильтр по клиентами действительно работает правильно во всех случаях.

Проверьте как работает RLS в отчетах. Откройте отчет со списком клиентов (Главное меню \ Расчеты с клиентами \ Отчеты \ Базовые данные \ Клиент). Попробуйте построить этот же отчет с фильтрами. Убедитесь, что фильтр по клиентам работает правильно и в отчетах.

Обратите внимание, что программисту не нужно ничего изменять или переделывать, чтобы в его отчете заработал RLS, если он в формах или для построения отчетов использовал ядро и не переопределял механизм получения данных. Если же программист вручную кодировл запросы, то ему необходимо добавить вызов метода recordLevelSecurity(true) для тех таблиц, где необходимо включить ограничение доступа на записи. См. подробнее руководство разработчика по ключевому слову Record Level Security.

Откройте заказы. Оп! А заказы показываются по всем клиентам. Почему? А потому, что в заказах содержатся коды клиентов, а не сами клиенты. Попробуйте перейти к основной таблице с клиентами - вы не сможете увидеть параметры скрытых клиентов.

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

Права доступа на уровне записей действуют не только в формах и отчетах, но и в выпадающих списках. Откройте заказ и нажмите на кнопку выпадающего списка у клиента. Да, все правильно. Пользователь Тест видит только прочих клиентов.

RLS для нескольких групп

Теперь рассмотрим ситуацию, когда необходимо настроить несколько разных групп с разными правами и с разными ограничениями прав.

Предположим, что одна группа менеджеров имеет доступ к Прочим клиентам (группа клиентов = Прч), а другая группа менеджеров имеет доступ к Обычным клиентам (группа клиентов = ТиУ). Первую группу мы уже настроили. Остается настроить вторую группу.

Повторите шаги 8-10. Только установите группе тстГруппа2 полные права на модуль Расчеты с клиентами и и в качестве критерия укажите "ТиУ" в настройке RLS для групы тстГруппа2.

Для проверки зайдите в Аксапту под пользователем Тест и убедитесь, что формы и отчеты работают корректно, убедитесь, что вы получили полные права на клиентов и можете редактировать параметры клиентов.

Что произойдет, если у клиента изменить группу? В форме клиент будет виден до тех пор, пока он не уйдет за пределы экранной формы. Как только Аксапта считает заново данные с сервера, сработает RLS и менеджер больше не увидит "чужого" клиента.

Этот пример снова показывает, что права надо настраивать комплексно. В данной ситуации можно либо запретить менеджерам редактирование поля группа клиентов, либо настроить ограничение на уровне записей (RLS) и на таблицу с группами.

Для того, чтобы некоторым пользователям разрешить доступ ко всему списку клиентов, необходимо третьей группе дать права на таблицу клиентов, но не настраивать RLS. Axapta смотрит на обычные права доступа. И, если право доступа есть, то смотрит в настройки RLS. Если для данной группы и данной таблицы настроек RLS нет, то Аксапта показывает все записи из таблицы.

Обратите внимание, что группа тстГруппа3 не влияла на поведение RLS до тех пор пока она не имела прав на таблицу клиентов. Как только в этой группе появилось право на клиентов, так сразу эта группа стала участвовать в RLS. Чтобы проверить этот тезис, уберите права на модуль Расчеты с клиентами в группе тстГруппа2 и проверьте RLS для клиента Тест. Вы увидите только прочих клиентов.

Роль является объектом метаданных, благодаря которому определяется, к какому объекту и какие действия над этим объектом может выполнять тот или иной пользователь. Каждая роль содержит права и в зависимости от того какие права установит администратор БД будут происходить разграничения доступа. В технологической платформе предусмотрено два типа прав, это: основные и интерактивные. Под основными понимаются права на Чтение, Изменение,Добавление и Удаление. Интерактивные осуществляются только при выполнение таких операций, как редактирование или удаление в форме: Интерактивное удаление, Интерактивное добавление и другие.

Таким образом можно раз и навсегда включить доступ к тому или иному справочнику, документу и другим объектом метаданных, причем целиком. Вы можете дать доступ или забрать. Дать на немножко у вас не получиться. Но ведь часто возникает такая ситуация, когда существует, к примеру, огромный справочник и каждый пользователь должен видеть только определенные элементы в нем. То есть по какому- то определенному условию должен происходить отбор элементов объекта! И вот начиная с версии технологической платформы 1С 8.1 появился очень мощный механизм ограничения доступа к данным на уровне записей под названием RLS (Record Level Security). Ограничения представляют собой набор определенных условий, при выполнении которых будет предоставлять доступ или нет.

Ограничения доступа при использовании динамической системы RLS применяется к основным операциям: Чтение, Изменение, Добавление и Удаление. Существует важная особенность, заключающаяся в том, что к операции Чтение может быть применено несколько ограничений на уровне записей, в то время как ко всем остальным операциям только одно условие. Данный механизм позволяет накладывать ограничения не только на определенные записи, но и на определенные поля записей. При чем указать возможно нужно поле, а так же специальное поле <Прочие поля>.

Синтаксис и язык RLS

Язык ограничения данных представляет собой ничто иное как язык запросов, но очень сильно урезанный. Если условие принимает значение ИСТИНА, то текущему пользователю предоставляется доступ к данным, если же ЛОЖЬ, тогда отказ. Какие же основные отличия от полноценного языка запросов?

В запросе RLS всегда присутствует только одна таблица данных и она собственно используется для условий.
Используются только конструкции ИЗ и ГДЕ.
В таких условиях можно указывать в качестве параметров запроса функциональные опции и параметры сеанса.
Не допускается использование виртуальных таблиц.
Возможно использование шаблонов для создания ограничений
Операторы ИТОГИ и В ИЕРАРХИИ не применимы.

Рассмотри как произвести ограничения. к примеру на рис. 1 приведено самое простое ограничение. Оно состоит в том, что пользователь увидит только одного контрагента с определенным наименованием «Сибирская Корона ООО». Можно производить фильтр по определенному полю. Например, мы хотим,чтобы пользователь видел только контрагентов, которые находятся в папке родителе «Сотрудники».

Текст ограничения может быть набран как вручную, а также может быть набран при использовании привычного конструктора запросов. Конструктор запросов в данном случае также будет не полноценен, а буден наделен ограничениями для RLS. В запрос ограничений можно также передавать любые параметры &.

Способы функционирования ограничений

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

• ВСЕ. То есть в процессе наложения ограничений операция выполняется над всеми требуемыми данными БД. Однако при прочтении и изменении данных, если не выполняются ограничения для каких то записей, то происходит аварийный сбой из за нарушения прав доступа.
• РАЗРЕШЕННЫЕ. Способ функционирования при котором в результате наложения ограничений должны быть прочитаны только те записи, которые удовлетворяют условиям. При этом аварийные сбои отсутствуют. Объекты не удовлетворяющие требованиям считаются отсутствующими.

Способ РАЗРЕШЕННЫЕ очень часто используется при формировании динамических списков, в противном случае постоянно бы появлялись ошибки о нарушении прав. Способ ВСЕ используется при получении объектов функциями встроенного языка и запросов. Собственно где устанавливаются данные способы? По умолчанию используется ВСЕ.

Использование шаблонов в RLS

Для более удобного использования ограничений в системе 1С предприятие предусмотрено использование шаблонов. То есть если вы используете одно и тоже ограничение или вы знаете,что оно будет отличаться только некоторыми параметрами, то вы создаете свой шаблон. Таким образом можно вообще оформить повторяющийся код ограничений как процедуру.Шаблон имеет имя и текст. Текст содержит программный код ограничений, в нем как и в процедуре можно использовать параметры, при чем параметры выделяются префиксом #.

Рассмотри на примере конфигурации 1С:Бухгалтерия 8.2 использование встроенных шаблонов. Откроем роль БУХГАЛТЕР и перейдем во вкладку Шаблоны ограничений. Здесь используется шаблон ОсновноеУсловиеЧтение следующего содержания:

Где мы видим #Параметр(1)=НастройкиПравДоступаПользователей.ОбъектДоступа. Это и есть тот самый параметр который может меняться в зависимости от передаваемых данных. Далее в любом месте где мы желаем ввести ограничения мы используем шаблон так:

То есть вместо

#Параметр(1)=НастройкиПравДоступаПользователей.ОбъектДоступа

в тексте шаблона окажется

Организация=НастройкиПравДоступаПользователей.ОбъектДоступа.

Или на более простом шаблоне. Наименование шаблона #МоиОграничения следующего содержания:

ГДЕ #Параметр(1) = &ТекущийПользователь

В результате передачи параметров в шаблон #МоиОграничения(“Исполнитель”) мы получаем следующее

ГДЕ Исполнитель= &ТекущийПользователь.

Итоги

Механизм ограничения доступа к данным на уровне записей очень мощная штука, но ее настройка требует большого опыта, так как в этих «дебрях» можно легко заблудиться. Благодаря ему можно производить любое частичное разграничение данных. С другой стороны добавление различных условий приводит к падению производительности системы, правда незначительной. Так как платформа 1С к запросу пользователя добавляет дополнительные запросы в виде ограничений. Во всем остальном- это просто отличная штука для разработчиков!

Каждый руководитель безоговорочно согласится с тем, что каждый сотрудник на предприятии должен иметь доступ только к той информации, которая лежит в его компетенции. Например, кладовщику на складе вовсе не обязательно просматривать, какие операции совершает финансовый директор или главный бухгалтер. Однако нередко возникают достаточно тонкие ситуации, например, когда программа 1С: Предприятие 8 используется не для одной, а для нескольких предприятий. На каждом из них работают свои сотрудники, которые должны иметь доступ только к разрешенной информации, относящейся к их предприятию.

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

Рассмотрим пример конкретной ситуации. В состав нашей компании входят две организации. Первая занимается продажей программного обеспечения, в вторая – обучением работе с ним. Для учета этих обеих организаций мы используем программный продукт 1С: Комплексная автоматизация 8 .

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

Первое, что приходит на ум при постановке данной задачи ― настройка отборов на организации. Однако это решение имеет два существенных недостатка:

• отборы придется настраивать во всех формах программы;
• для более ли менее сообразительного пользователя абсолютно не составит труда их отключить.

Самый верный способ - это разграничить доступ пользователей на уровне записей. Как же это реализовать?

Первое, что необходимо выполнить ― включить в программе возможность использования данного способа. Для этого необходимо:

В нашем случае необходимо ввести ограничение доступа по организациям, однако видно, что программа предоставляет возможности намного шире. Например, разграничить доступ по справочникам и документам.

Аналогичный механизм реализован и в других прикладных решениях 1С:

• (редакция 10.3)
• и 1С: Зарплата и управление персоналом 8 (редакция 2.5).

В этих программах разграничение прав доступа осуществляется с помощью справочника «Группы пользователей», который доступен из меню «Сервис», раздела «Настройка доступа пользователей».

• Таким образом, в этих программах нам необходимо всех наших пользователей, работающих в составе компании, поделить на группы по организациям.
• Затем нажать кнопку «Настройка доступа».
• В появившемся окне нажимаем кнопку «Добавить» и вводим объект доступа (в нашей ситуации это организация).
• Если нам необходимо разрешить сотрудникам организации вносить данные в информационную базу данных, то необходимо поставить флажок в столбце «Запись».

Эти действия необходимо выполнить для каждой организации. После этого, каждый сотрудник после входа в программу будет видеть только те документы, которые определены его правами доступа по должности и относятся к его организации.