Для чего нужны параметры сеанса при работе с rls
Настройка RLS в 1С — ограничение доступа на уровне записей
Ранее мы рассматривали настройку ролей пользователей в системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).
Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.
1С RLS (Record Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.
Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).
Преимущества ограничения прав на уровне записей в 1С
Основное преимущество — наличие механизма вообще, механизм достаточно сложный и интересный. Позволяет очень тонко разграничить права пользователей — пользователи могут даже не догадываться о существовании в системе других данных.
Недостатки 1С 8 RLS
Среди недостатков можно отметить заметное падение производительности системы. Это вызвано тем, что платформа при построении запроса в базе данных осложняет любой запрос разработчика дополнительными условиями.
Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.
Настройка ограничения прав на уровне записей 1С RLS
Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:
##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли
По сути, этот запрос каждый раз добавляется при запросе к таблице «#ТекущаяТаблица». Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.
Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — «Параметры сеансов«. Как правило, они задаются при старте сессии пользователя.
Конструктор ограничения доступа к данным
Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:
Другие статьи по 1С:
Пример настройки RLS:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
RLS – гибкая и тонкая настройка ограничений доступа к данным
Классическая задача: открыть пользователю доступ к какому-либо объекту, но не ко всем элементам / документам, а только к некоторым.
Или это может быть ограничение “все, кроме некоторых”.
Или ограничение не на справочники/документы, а на данные регистров…
По сути – это тонкая и очень гибкая настройка “что можно видеть этому пользователю, а о чем ему и не нужно догадываться”.
Почему именно RLS?
На большинстве внедрений требуется для разных пользователей установить различные уровни доступа к информации в базе.
В конфигурациях за возможные права доступа к данным отвечают специальные объекты метаданных – роли. Каждому пользователю информационной базы назначается одна или несколько ролей. Они определяют, возможны ли операции с конкретными объектами метаданных (чтение, запись, проведение и т.д.).
Часто бывает необходимо не просто открыть/запретить доступ к определенному объекту, а ограничить доступ к части данных в нем.
Только при помощи ролей решить такую задачу нельзя – для этого реализован механизм ограничения доступа на уровне записей (RLS).
Ограничения представляют собой условия, при выполнении которых действие над данными (чтение, запись и т.д.) будет разрешено. – так можно ограничить доступ не к объекту в целом, а только к части его данных.
Про RLS – более подробно: 8 видео и PDF
Поскольку это распространенная задача администрирования 1С – предлагаем посмотреть более детальные материалы:
PDF с вводной информацией.
21 страница, которые нужно прочесть сначала.
Видео 01:
Ограничение доступа к данным при помощи ролей
В этом видео рассказывается, как ограничивается доступ к данным при помощи ролей. Уточняется, что роли ограничивают доступ к виду объектов информационной базы (отдельный справочник, но не конкретные элементы справочника).
Видео 02:
Ограничение доступа на уровне записей (RLS)
В этом видео рассказывается о механизме ограничений доступа на уровне записей (RLS), когда можно настроить доступ не ко всему справочнику в целом, а к отдельным его элементам, в зависимости от хранящихся в информационной базе данных. Подобные ограничения прописываются в ролях.
Видео 03:
Реализация ограничения доступа на уровне записей для справочника Контрагенты
В этом видео рассказывается, как в демонстрационной конфигурации «Управляемое приложение» настроить доступ менеджеров только к собственным контрагентам, закрепленным за ними.
Видео 04:
Принцип работы ограничений доступа на уровне записей на низком уровне
В этом видео рассказывается, как платформа трансформирует запросы, передаваемые для выполнения на сервер СУБД, при наличии ограничений доступа на уровне записей.
Видео 05:
Совместное применение нескольких ограничений доступа на уровне записей
Пользователю информационной базы может быть назначено несколько ролей. При этом в каждой роли могут быть свои ограничения доступа на уровне записей. В этом видео рассказывается, как ведет себя система при наложении ограничений.
Видео 06:
Наложение ограничений методом ВСЕ
В этом видео описывается первый способ наложения ограничений на уровне записей – метод ВСЕ. При этом, если в выборку попадают записи, к которым доступ ограничен, будет выведено сообщение об ошибке.
Видео 07:
Наложение ограничений методом РАЗРЕШЕННЫЕ
В этом видео описывается первый способ наложения ограничений на уровне записей – метод РАЗРЕШЕННЫЕ. При этом в выборку попадут только те записи, к которым у пользователя есть права доступа.
Видео 08:
Исправление ошибки, возникающей из-за наложения прав доступа на уровне записей
В этом видео рассматривается, как при помощи ключевого слова РАЗРЕШЕННЫЕ исправить ошибку, возникающую под пользователем с ограниченными правами.
Не пропустите – все сразу и в полном объеме!
Этот курс позволит решать ВСЕ задачи по развертыванию и поддержке информационных систем на 1С.
Вот несколько тем из курса:
Даже на 3-5 пользователей. Тем более – если их хотя бы десяток…
Вам в любом случае когда-то придется разворачивать 1С, настраивать резервирование, права доступа, различные режимы запуска, тестировать целостность баз, обеспечивать работу серверов и т.д.
И лучше это сразу делать правильно.
Чтобы потом не было “…! Ну что за …! Твою же …!” – и прочих выражений сожаления 🙂
Комментарии / обсуждение (161):
Добрый день!
Используется конфигурация 1С:ERP 2.4. Учет в базе ведется более 3 лет, 150 пользователей.
Механизм ограничения доступа на уровне записей ранее не был включен. При включении опции “Ограничивать доступ на уровне записей” предупреждается, что выполнение заполнения данных при этом будет выполняться частями и может замедлить работу программы.
Вопрос 1. Заполнение данных, пусть и частями, будет выполнено один раз?
В курсе «Настройка и доработка прав доступа, профилей пользователей и RLS в типовых конфигурациях УТ 11.4 (11.3), КА 2.4 (2.2) и 1C:ERP 2.4 (2.2)» говорится, что при включенной указанной опции работа пользователей может быть замедлена в части работы интерфейса.
Вопрос 2. На сколько работа пользователей может быть замедлена, при размере базы 300 Гб?
Добрый день!
1. Для того, чтобы работали ограничения доступа на уровне записей, в служебных регистрах сведений должны быть записи, описывающие доступ к отдельным объектам.
До включения указанной галочки в регистрах не было нужных записей, значит, первоначально нужно сформировать эти записи по всей базе, затем поддерживать регистр в актуальном состоянии по мере заполнения базы новыми данными.
Для выполнения этого действия в конфигурациях на базе БСП (ERP как раз к таким относится) существует специальное регламентное задание, которое выполнит первоначальное заполнение (разовая операция), затем будет доформировывать записи для новых объектов (это уже будет регулярная операция, которая должна часто выполняться, чтобы для всех новых объектов базы были сформированы записи в регистрах, отвечающих за ограничения доступа).
2. Замедление работы зависит от нескольких факторов – какой режим ограничений будет выбран (стандартный и производительный), а также какое количество групп доступа будет у каждого пользователя. В общем случае – чем больше групп доступа у пользователя, тем сложнее может получиться запрос к СУБД, который извлекает данные из базы.
Поэтому рекомендуется провести нагрузочное тестирование на копии базы в условиях, приближенных к реальной работе пользователей. Тогда Вы точно сможете оценить степень замедления работы системы.
Добрый день!
Подскажите, пожалуйста, как можно с помощью шаблонов ограничения доступа ограничить доступ к данным некоторых отчетов. Например, есть профиль Менеджер по продажам, состоящий из нескольких ролей, у которого настроено ограничение доступа к группе партнеров. Исключения настроены в группе доступа. В отчете, например, Воронка продаж, нужно установить ограничение на разрешенную группу партнеров. А в другом отчете, например, Анализ встреч, по текущему пользователю, но также для пользователя с данным профилем.
Добрый день!
В типовых конфигурациях на базе БСП (например, УТ 11) в ролях используются стандартные шаблоны ограничений доступа из БСП.
Они универсальные, поэтому для решения большинства задач их не требуется менять. Предполагается, что настройку нужно выполнять в пользовательском режиме, создавая профили и группы доступа.
Если Вы ограничиваете доступ к справочнику Партнеры, оставляете доступными определенные группы, то в форме списка справочника, в списке документов, в отчетах будут видны данные только по этим разрешенным партнерам. Других (запрещенных) партнеров и данных по ним увидеть нельзя.
Если нужно в отчетах видеть не всех разрешенных партнеров, а только часть из них, то можно настроить отборы в отчете и сохранить такой вариант отчета. В отборе указать конкретных разрешенных партнеров, тогда отчет будет формироваться только по ним. Сохраненный вариант отчета можно разместить в Избранном, тогда пользователь сможет быстро формировать его, не выполняя предварительную настройку.
Добрый день, в учебной версии при использовании rls столкнулся с проблемой при записи или проведении документа (у пользователя недостаточно прав на использование операций над базой данных), причём в полной версии 1с данной проблемы не встречал.
В журнале регистраций ссылается на отказ доступа (действие-чтение)
Ограничение делал простое:
Как можно решить данную проблему?
Заранее огромное спасибо!
P.S.: не судите строго я недавно начал изучать 1с.
У учебной версии нет ограничений по RLS. Проверяйте, скорее всего у пользователя действительно недостаточно прав на использование операций над базой данных.
Добрый день!
Хотел уточнить, при установки ограничения по текущему пользователю на документ, сам пользователь проводить свои документы может или он их сможет только просмотреть и ему всё же будет отказано в доступе, как в моем случае?
Это зависит от-того на какое право наложено ограничение, чтение или запись.
Часто возникает необходимость в частичном ограничении доступа к данным. Например, когда пользователь должен видеть документы только своей организации. В таких случаях в 1С используется механизм ограничения доступа на уровне записей (так называемый, RLS – Record Level Securiy).
Для примера предположим, что перед нами стоит следующая задача. На предприятии ведется многофирменный учет и каждый контрагент и пользователь базы данных относится к определенной организации. Необходимо обеспечить доступ к справочнику “Контрагенты” таким образом, чтобы каждый пользователь мог просматривать, редактировать и добавлять контрагентов только своей организации.
Для решения задачи будем использовать платформу “1С:Предприятие 8.2″. Создадим новую конфигурацию в свойствах которой в качестве основного режима запуска будет выбран вариант “Управляемое приложение”.
Далее создадим справочник “Организации” и ещё два справочника – “Контрагенты” и “Пользователи” с реквизитом “Организация”. Кроме справочников нам понадобятся два параметра сеанса – “Организация” и “Пользователь” (соответствующих типов). Значения этих параметров устанавливаются при запуске сеанса работы с конфигурацией и хранятся до его завершения. Именно значения этих параметров мы и будем использовать при добавлении условий ограничения доступа на уровне записей.
Установка параметров сеанса выполняется в специальном модуле – “Модуль сеанса”
В этом модуле опишем предопределенную процедуру “УстановкаПараметровСеанса” в которой вызовем функцию заранее подготовленного общего модуля “ПолныеПрава”. Это необходимо в силу особенностей работы базы данных в режиме управляемого приложения, когда часть программного кода может выполняться только на стороне сервера (подробно на объяснении этих принципов в данной статье я останавливаться не буду).
В свойствах модуля “ПолныеПрава” необходимо отметить флажки “Сервер”, “Вызов сервера” и “Привилегированный” (последнее означает, что процедуры и функций данного модуля будут выполнятся без контроля прав доступа). Текст модуля будет выглядеть так:
В модуле управляемого приложения будем проверять наличие пользователя конфигурации в справочнике “Пользователи” (для простоты будем искать его по наименованию) и завершать работу системы если он не найден. Это необходимо для того, чтобы обеспечить заполнение параметров сеанса.
Теперь можем перейти непосредственно к описанию ограничений доступа. Для этого создадим роль “Пользователь” и перейдем на закладку “Шаблоны ограничений”, где добавим новый шаблон “КонтрагентыЧтениеИзменение” со следующим текстом шаблона: ГДЕ Организация =Организация #Параметр(1)
Текст шаблона ограничений является расширением языка запросов. В отличии от обычного запроса, текст ограничения должен в обязательном порядке содержать условие “ГДЕ”. В качестве значений параметров запроса (в нашем случае это “&Организация”) используются значения одноименных параметров сеанса. Конструкция вида #Параметр(1) означает, что на это место система подставит текст, переданный в качестве первого параметра в месте использования шаблона. С помощь приведенного шаблона будет выполняться проверка каждой записи таблицы (в нашем случае это будет справочник “Контрагены”). Для записей, значение реквизита “Организация” которых совпадает с заданным в соответствующем параметре сеанса, условие описанное в шаблоне будет выполняться. Таким образом эти записи будут доступны для чтения, изменения или добавления (в зависимости от того для какого из этих прав применяется шаблон). Продемонстрирую вышеизложенное на нашем примере.
Перейдем на закладку “Права” роли “Пользователь” и откроем список прав справочника “Контрагенты”. Будем использовать шаблон ограничений “КонтрагентыЧтениеИзменеие” для прав “Чтение”, “Изменение” и “Доблавление”.
Для права “Чтение” будем использовать шаблон с параметром “ИЛИ ЭтоГруппа”. При этом пользователям данной роли будет разрешено чтение не только элементов справочника “Контрагенты” своей организации, но и всех групп этого справочника.
#КонтрагентыЧтениеИзменение(«ИЛИ ЭтоГруппа»)
Поскольку при добавлении новых элементов справочника системой выполняется неявное чтение предопределенных реквизитов (это нужно, например, для нумерации), то необходимо обеспечить беспрепятственное чтение этих полей. Для этого добавим дополнительную строку с пустым текстом ограничения в таблицу ограничения доступа к данным и перечислим поля для которых действует данное правило – Ссылка, Версия данных, Родитель, Код.
Таким образом, поставленная задача ограничения доступа на уровне записей решена. Пользователи с действующими ограничениями получат доступ на просмотр и редактирование данных только своей организации.