Проверка прав доступа
Область применения: управляемое приложение, обычное приложение.
1. В случае большого количества ролей в конфигурации (от нескольких десятков) не рекомендуется использовать ролевую настройку видимости в элементах форм (просмотр и редактирование реквизитов по ролям, пользовательскую видимость полей формы по ролям, использование команд по ролям). Вместо этого следует придерживаться следующих подходов:
- при сильных различиях внешнего вида и функциональности формы в зависимости от наличия тех или иных ролей у пользователя – разрабатывать отдельные формы, специализированные под конкретный набор прав пользователя;
- при незначительных отличиях – выполнять проверку прав в коде. При этом следует иметь в виду, что программное управление видимостью может снизить скорость открытия формы, что нужно учитывать при выборе между предлагаемыми подходами.
Эти меры позволяют:
- существенно упростить работу из кода с элементами управления, которые пропадают из коллекции Элементы (код Элементы.ИмяЭлемента.ИмяСвойства становится нерабочим);
- повысить устойчивость кода к пересмотру состава ролей в конфигурации;
- организовать контроль использования ролей в конфигурации (в противном случае, выполнять анализ прав доступа по флажкам, назначенных для ролей в различных элементах произвольных форм конфигурации, крайне затруднительно).
2. Не рекомендуется использовать ролевую настройку видимости в командном интерфейсе конфигурации, командном интерфейсе основного раздела, а также рабочей области начальной страницы. Вместо этого следует использовать настройку прав на разделы командного интерфейса, общие формы и объекты, включенные в командный интерфейс или в рабочую область. Это позволяет повысить предсказуемость поведения управляемого интерфейса для пользователя, а также упростить расследование ошибок.
3. Для проверки прав доступа в коде следует использовать метод ПравоДоступа .
Например, неправильно:
Если РольДоступна(«ДобавлениеИзменениеСтранМира») Тогда .
Если РольДоступна(«ПросмотрОтчетаПопулярныеСтраны») Тогда .
Если ПравоДоступа(«Редактирование», Метаданные.Справочники.СтраныМира) Тогда .
Если ПравоДоступа(«Просмотр», Метаданные.Отчеты.ПопулярныеСтраны) Тогда .
Такой подход позволяет повысить устойчивость кода к пересмотру состава ролей в конфигурации.
4.1. В тех случаях, где роль не дает никаких прав на объекты метаданных, а служит только для определения того или иного дополнительного права, следует использовать метод РольДоступна . При использовании в конфигурации Библиотеки стандартных подсистем (БСП) следует использовать функцию РолиДоступны общего модуля Пользователи :
Например, без использования БСП:
Если РольДоступна(. ) Или Или ПривилегированныйРежим() Тогда .
Либо аналогичная проверка с использованием БСП:
Если Пользователи.РолиДоступны(. ) Тогда .
4.2. Следует проектировать роли с учетом их влияния на командный интерфейс. В тех случаях, когда чтение или запись данных ведется в привилегированном режиме, не следует указывать в роли права с условием ограничения на уровне записей (RLS) ГДЕ ЛОЖЬ . Вместо этого следует проверять наличие роли.
Например, права на общую форму Заметка дают роли ДобавлениеИзменениеЗаметок и ЧтениеЗаметок . Обращение к данным заметок при этом выполняется в привилегированном режиме. В этом случае с помощью метода ПравоДоступа невозможно определить, можно ли пользователю добавлять заметки по наличию права на форму Заметка .
Добавить в роль ДобавлениеИзменениеЗаметок фиктивные права на регистр сведений Заметки (с условием ограничения ГДЕ ЛОЖЬ ) и выполнять проверку:
Если ПравоДоступа(«Редактирование», Метаданные.РегистрыСведений.Заметки) Тогда
Если РольДоступна( «ДобавлениеИзменениеЗаметок» ) Или Или ПривилегированныйРежим() Тогда
Либо аналогичная проверка с использованием БСП:
// АПК:515-выкл — №737.4.2 – Допустимо проверять роль, так как в ней нет прав,
// позволяющих определить может ли пользователь добавлять заметки.
Если Пользователи.РолиДоступны(«ДобавлениеИзменениеЗаметок») Тогда
// АПК:515-вкл
- Стандартные роли
- Разработка ролей в библиотеках
Настройка ролей и прав доступа
Область применения: управляемое приложение, обычное приложение.
Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.
1. Общие положения
1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.
Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.
Например, в УП(ERP) это роль ПартнерСамообслуживание .
1.2. Роль ПолныеПрава (англ. FullAccess ) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator ) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.
1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы ) не должна давать право на интерактивное удаление ссылочных объектов.
- после создания нового объекта нужно зайти в роль ПолныеПрава и отключить право интерактивного удаления у ссылочных объектов.
1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.
1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.
1.6. Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета или обработки), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы , создавать отдельные роли в этом случае не требуется.
1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.
Исключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.
1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».
Исключение: в конфигурации могут быть предусмотрены параметризированные ФО, для которых разработчик специально предусматривает различия в получаемых значениях пользователями с разными правами.
Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом , которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.
1.9. Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование , ТонкийКлиент и т.п.).
- при создании новой роли нужно следить, чтобы эти права были выключены.
1.10. В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке — для ссылочных данных), а следует включать эти права в роли БазовыеПрава (англ. BasicAccess ) и БазовыеПраваВнешнихПользователей (англ. BasicAccessExternalUser ) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.
1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
Пример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
3. Ссылочные объекты и регистры
3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
- Чтение (англ. Read );
- ДобавлениеИзменение (англ. AddEdit ) или Изменение (англ. Edit ), если добавление выполняется автоматически, либо только администратором.
Роли должны содержать следующие права (когда они имеются у объекта метаданных):
Программно проверить наличие роли у пользователя 1С
Если вам в программном коде 1С 8 необходимо проверить установлена ли какая либо роль у текущего пользователя, то воспользуйтесь функцией глобального контекста РольДоступна() , которая возвращает значение Истина, если указанная в скобках роль доступна и Ложь, если не доступна. Наименование проверяемой роли следует писать в кавычках.
Пример: При проведении некоторого документа вам нужно проверять установлена ли у пользователя проводящего его роль ПолныеПрава, если доступна то выполнять процедуру проведения, если нет, то выдавать сообщение: “Для проведения данного документа необходима роль Полные права”.
Решение: В начале процедуры ОбработкаПроведения напишите следующий код:
Если НЕ РольДоступна("ПолныеПрава") Тогда Сообщить("Для проведения данного документа необходима роль Полные права"); Отказ = Истина; КонецЕсли;- Создание нового пользователя в 1С 8.2
- Настройка двухстороннего обмена данными между конфигурациями «Управление торговлей 10.3» и «Бухгалтерия предприятия 2.0» в 1С 8
- Администрирование 1С 8.3 с нуля для начинающих
- Поиск в справочнике 1С
Как получить список ролей для пользователя.
Имеется список пользователя (тип строка), нужно для каждой строки определить доступные роли.
Спасибо!.
По теме из базы знаний
- Всякие полезности
- Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?
- Упрощенная обработка по просмотру прав по ролям на объекты конфигурации
- Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS
- Как я писал ТЗ на внедрение 1С:ERP
- Дата
- Дата
- Рейтинг всех уровней
- Рейтинг 1-го уровня
- Древо развёрнутое
- Древо свернутое
Свернуть все
3. M.Shalimov 200 19.11.12 20:06 Сейчас в теме
ПользователиИнформационнойБазы.НайтиПоИмени("ИмяПользователя").Роли;
LiebeMein; KAV2; Nikitos_NSK; Hogyoku; indefinitum000; GonziK_KIV; user843810; petronas; alexvid; Dudasmit; + 10 – Ответить