v8: Права пользователей в 1С:Предприятии 8.0
Ключевые слова: юзер, запретить, разрешить, роль, право, доступ, аутентификация, ограничения, RLS, РАЗРЕШЕННЫЕ, привилегированные, ТекущийПользователь
1.1.1 Базовые возможности
Список пользователей задается в Конфигураторе, редактируется "на лету", т.е. без монопольного захвата базы.
Каждому пользователю могут быть доступны несколько ролей (отличие от 7.7, где у пользователя могла быть только одна роль).
Права доступа назначаются для ролей. Если хотя бы одна роль пользователя разрешает действие над объектом, то доступ разрешен. Понятие «доступ не назначен» полностью аналогично «доступ запрещен» (флажок может быть установлен или нет, т.е. нет третьего состояния).
Два режима идентификации:
• аутентификация средствами 1С:Предприятия (логин и пароль):
при запуске пользователь должен выбрать (ввести) свое имя и ввести пароль
можно настроить ярлык для быстрого доступа к базе
• аутентификация средствами Windows (имя пользователя в домене)
пароль вводить вообще не нужно, просто запустить 1С и выбрать базу
меньше списков пользователей и паролей – меньше работы администратору
Возможен программный доступ к списку пользователей. Для этого пользователь должен иметь административные права. Доступ осуществляется через свойство ПользователиИнформационнойБазы глобального контекста. Можно читать пользователей, создавать новых, удалять, изменять. Поле «Пароль» доступно только на запись (т.е. установить программно пароль можно, а прочитать нельзя).
1.1.2 Ограничения на права доступа (на уровне записей - RLS)
Начиная с релиза 8.0.7 платформа 1С:Предприятие позволяет реализовать то, что называется RLS – Record Level Security, или «ограничение доступа на уровне записей». Для каждого вида права из нижеперечисленных можно задавать ограничения:
• Чтение
• Добавление
• Изменение
• Удаление
Ограничения задаются не для конкретных записей (элементов справочника, документов, записей регистров), а для ПОДМНОЖЕСТВА, которое определяется условием выборки (ограничением). Ограничение задается с помощью подмножества языка запросов – конструкции ГДЕ.
Если условие дает значение ИСТИНА, то доступ разрешен, иначе – доступ запрещен.
Ограничение на право «чтение» может задаваться для каждого поля в отдельности или для списка полей. То есть можно организовать так, чтобы поля ЗакупочнаяЦена и МаксимальнаяСкидка справочника Номенклатура были видны, если только уровень доступа пользователя (число) позволяет обращаться к данной позиции номенклатуры.
В условии запись «МаксимальныйУровеньДоступа» является ссылкой на параметр сеанса (см. Книга знаний: v8: Параметры сеанса). Так же можно задействовать поле «Пользователь», например, организовать доступ менеджеров к «своим» контрагентам.
Заданные ограничения добавляются системой к КАЖДОМУ запросу, даже тем, которые платформа генерирует самостоятельно для реализации пользовательского интерфейса или других функций. Отсюда – значительное снижение производительности. Поля, по которым накладывается ограничение (УровеньДоступа в вышеприведенном запросе) должны быть проиндексированы.
Ограничения на доступ к данным работают в двух режимах:
• в режиме динамического списка производится простая фильтрация разрешенных записей, таким образом, пользователь просто не видит запрещенные данные.
• в режиме выборки – нарушение ограничения влечет за собой исключение, таким образом, запрос не будет выполнен вовсе, значит, практически все запросы конфигурации могут «налететь» на ограничение.
Нюанс предложения "В ИЕРАРХИИ"
В платформе 8.0 (да и 8.1) в условиях ограничений нельзя использовать выражение "В ИЕРАРХИИ" в силу очевидной ресурсоемкости запроса. Данный факт зело смущает неокрепшие умы и они (умы) начинают думать, что, если нужно ограничить доступ в какую-либо группу справочника с неограниченной иерархией, то RLS не подходит. Справедливости ради, нужно отметить, что для означенной цели использовать RLS таки можно довольно таки невозбранно и вариантов для этого масса. Один из таких вариантов — предложение В и фиксированный массив в параметре сеанса. Не быстро и не без некоторых ограничений, но работать будет.
Кроме того, особо любопытные камрады могут посмотреть, как в типовых реализовано разграничение доступа к справочникам номенклатуры и контрагентов на основе групп пользователей — там это разграничение реализовано на основе RLS и таки можно настраивать доступ к группам.
1.1.3 Ключевое слово РАЗРЕШЕННЫЕ языка запросов
В язык запросов было введено новое ключевое слово «Разрешенные», которое пишется сразу после «Выбрать». Если оно указано, то запрос выбирает только разрешенные записи, а остальные «не видит».
Такое простое изменение конфигурации возможно путем замены в каждом запросе «ВЫБРАТЬ» на «ВЫБРАТЬ РАЗРЕШЕННЫЕ».
1.1.4 Привилегированные общие модули
Для реализации некоторых задач нужно отключить контроль прав доступа. Например, для реализации обмена данными, для контроля прав доступа средствами конфигурации и т.д. Таким образом, некоторый участок программного кода должен выполняться БЕЗ КОНТРОЛЯ ОГРАНИЧЕНИЙ. Это достигается размещением такого программного кода в общем модуле и установкой у него флага ПРИВИЛЕГИРОВАННЫЙ.
В трехзвенной архитектуре (клиент-сервер) привилегированные модули выполняются на сервере 1С:Предприятия 8.0.
«Защитное» программирование привилегированных процедур и функций
Доступ к таким процедурам и функциям должен контролироваться. Вызовы этих процедур нужно минимизировать, концентрировать. В самой процедуре формальные параметры должны проходить жесткий и полный контроль. Не рекомендуется использовать там конструкции Выполнить и Вычислить, а также обращение через квадратные скобки [ИмяФормальногоПараметра]. Нарушение этих правил может привести к обходу ограничения, заданного в конфигураторе.
1.1.5 Неожиданные эффекты
Новую систему прав доступа нужно использовать очень осторожно и осмотрительно. Только для тех данных, для которых это необходимо. Это может привести
• резкому снижению производительности.
• нарушению прав доступа в неожиданных местах, например, при формировании отчета по остаткам сработает ограничение на доступ к складам, возникнет - исключение.
• если используется ключевое слово Разрешенные или динамические списки, то возможны неожиданные визуальные эффекты:
а) в справочнике с автонумерацией невозможно ввести новый элемент (поле Код недоступно для чтения, а система не может прочитать максимальный код, чтобы увеличить его на 1 и присвоить код новому элементу).
б) в справочнике пропали все элементы, потому что при задании ограничения не был учтен доступ к ГРУППАМ иерархического справочника
См. также:
Книга знаний: v8: Программное управление списком пользователей
http://www.v8.1c.ru/overview/PlRights.htm
Книга знаний: v8: Элегантная реализация прав доступа в 1С 80 |