Использование параметров сеанса

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1.1. Параметры сеанса предназначены для хранения значений определенных типов для каждого клиентского сеанса на время работы этого сеанса. Инициализацию параметров сеанса следует выполнять в модуле сеанса (см. ниже раздел 2.1), а их значения рекомендуется использовать в запросах и условиях ограничения доступа к данным для текущего сеанса.
Примеры параметров сеанса:

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

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

ГДЕ Документ.Автор = &ТекущийПользователь

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

1.2. Не рекомендуется использовать параметры сеанса для хранения значений, используемых исключительно в клиентской логике. Поскольку в клиент-серверном варианте 1С:Предприятия параметры сеанса хранятся на сервере, то любое их считывание или изменение в процессе работы на клиенте потребует дополнительного серверного вызова и увеличит объем передаваемых данных с клиента на сервер и обратно.

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

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

Установка параметров сеанса «по требованию»

2.1. Не следует производить инициализацию параметров сеанса при запуске программы, так как:

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

Пример установки параметров сеанса «по требованию»:

Если ИменаПараметровСеанса = Неопределено Тогда
// Раздел установки параметров сеанса при начале сеанса (ИменаПараметровСеанса = Неопределено)
// Выполняется установка параметров сеанса, которые можно инициализировать
// при начале работы системы

Иначе
// Установка параметров сеанса «по требованию»

// Параметры сеанса, инициализация которых требует обращения к одним и тем же данным
// следует инициализировать сразу группой. Для того, чтобы избежать их повторной инициализации,
// имена уже установленных параметров сеанса сохраняются в массиве УстановленныеПараметры
УстановленныеПараметры = Новый Массив;
Для Каждого ИмяПараметра Из ИменаПараметровСеанса Цикл
УстановитьЗначениеПараметраСеанса(ИмяПараметра, УстановленныеПараметры);
КонецЦикла;

Если ИмяПараметра = «ТекущийПользователь» Тогда
ПараметрыСеанса.ТекущийПользователь = ;
ПараметрыСеанса. = ;
УстановленныеПараметры.Добавить(ИмяПараметра);
УстановленныеПараметры.Добавить(» «);
КонецЕсли;

Источник

Часто возникает необходимость в частичном ограничении доступа к данным. Например, когда пользователь должен видеть документы только своей организации. В таких случаях в 1С используется механизм ограничения доступа на уровне записей (так называемый, RLS – Record Level Securiy).

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

Для решения задачи будем использовать платформу “1С:Предприятие 8.2″. Создадим новую конфигурацию в свойствах которой в качестве основного режима запуска будет выбран вариант “Управляемое приложение”.

Далее создадим справочник “Организации” и ещё два справочника – “Контрагенты” и “Пользователи” с реквизитом “Организация”. Кроме справочников нам понадобятся два параметра сеанса – “Организация” и “Пользователь” (соответствующих типов). Значения этих параметров устанавливаются при запуске сеанса работы с конфигурацией и хранятся до его завершения. Именно значения этих параметров мы и будем использовать при добавлении условий ограничения доступа на уровне записей.

Установка параметров сеанса выполняется в специальном модуле – “Модуль сеанса”

В этом модуле опишем предопределенную процедуру “УстановкаПараметровСеанса” в которой вызовем функцию заранее подготовленного общего модуля “ПолныеПрава”. Это необходимо в силу особенностей работы базы данных в режиме управляемого приложения, когда часть программного кода может выполняться только на стороне сервера (подробно на объяснении этих принципов в данной статье я останавливаться не буду).

В свойствах модуля “ПолныеПрава” необходимо отметить флажки “Сервер”, “Вызов сервера” и “Привилегированный” (последнее означает, что процедуры и функций данного модуля будут выполнятся без контроля прав доступа). Текст модуля будет выглядеть так:

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

Теперь можем перейти непосредственно к описанию ограничений доступа. Для этого создадим роль “Пользователь” и перейдем на закладку “Шаблоны ограничений”, где добавим новый шаблон “КонтрагентыЧтениеИзменение” со следующим текстом шаблона: ГДЕ Организация =Организация #Параметр(1)

Текст шаблона ограничений является расширением языка запросов. В отличии от обычного запроса, текст ограничения должен в обязательном порядке содержать условие “ГДЕ”. В качестве значений параметров запроса (в нашем случае это “&Организация”) используются значения одноименных параметров сеанса. Конструкция вида #Параметр(1) означает, что на это место система подставит текст, переданный в качестве первого параметра в месте использования шаблона. С помощь приведенного шаблона будет выполняться проверка каждой записи таблицы (в нашем случае это будет справочник “Контрагены”). Для записей, значение реквизита “Организация” которых совпадает с заданным в соответствующем параметре сеанса, условие описанное в шаблоне будет выполняться. Таким образом эти записи будут доступны для чтения, изменения или добавления (в зависимости от того для какого из этих прав применяется шаблон). Продемонстрирую вышеизложенное на нашем примере.

Перейдем на закладку “Права” роли “Пользователь” и откроем список прав справочника “Контрагенты”. Будем использовать шаблон ограничений “КонтрагентыЧтениеИзменеие” для прав “Чтение”, “Изменение” и “Доблавление”.

Для права “Чтение” будем использовать шаблон с параметром “ИЛИ ЭтоГруппа”. При этом пользователям данной роли будет разрешено чтение не только элементов справочника “Контрагенты” своей организации, но и всех групп этого справочника.

#КонтрагентыЧтениеИзменение(«ИЛИ ЭтоГруппа»)

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

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

Источник

Нужна помощь: Ошибка >: Требуется актуализировать ограничение доступа по причине: Не удалось определить вариант ограничения доступа в параметрах сеанса для шаблона ДляОбъекта со значением параметра «». Объект: «Справочник.Ном

Добрый день.
Нужна помощь! Уже неделю голову ломаю, не пойму, что упустила(
Есть Конфигурация: Бухгалтерия государственного учреждения, редакция 2.0 (2.0.73.23)
Стоит задача в ней настроить Ограничение доступа на уровне записей к Справочнику «Номенклатура».

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

Мои действия:
1. Подчинила «Номенклатура» справочнику «Организация» т.е. «Номенклатуре» задала Владельца «Организация» (по аналогии с «Подразделениями»)
2. В МодульМенеджера «Номенклатура» добавила:

тоже скопировала из «Подразделения»!

3. В Роль ДобавлениеИзменениеНоменклатуры (она в типовой конфигурации присутствует, без ограничения доступа к данным) и БазовыеПраваБГУ, добавина на Чтение:

а на Добавление и Изменение:

Взяла из «Подразделения», изменила Справочник.Подразделения на Справочник.Номенклатура.

4. Сверила Шаблоны ограничений, они в Пользователе, Подразделениях и Сотрудниках одинаковые их тоже скопировала.
5. Добавила «Номенклатура» в ОпределяемыеТипы в:
ВладелецЗначенийКлючейДоступа
ВладелецЗначенийКлючейДоступаОбъект
ЗначениеДоступа
ЗначениеДоступаОбъект

Источник

Не удалось определить вариант ограничения доступа в параметрах сеанса для шаблона для объекта

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

Роли, права доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Контрагенты ГДЕ #ШаблонКонтрагент(«Ссылка») ИЛИ ЭтоГруппа»

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

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

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

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

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

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

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

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

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

Источник