В процессе разработки и администрирования систем на базе 1С:Предприятие часто возникает задача программного контроля прав доступа. Нам может потребоваться проверить наличие определенной роли у текущего пользователя или у любого другого пользователя информационной базы. Рассмотрим подробно все доступные механизмы, разберем типичные ошибки и выясним, как правильно ограничивать доступ к данным.
Самый простой и быстрый способ проверить права текущего сеанса — использовать встроенную функцию платформы РольДоступна. Этот метод работает на уровне метаданных и возвращает Истина, если у пользователя, под которым запущена программа, есть указанная роль.
Разберем пример реализации запрета изменения справочника Номенклатура:
Если НЕ РольДоступна("ИзменениеНоменклатуры") Тогда
Сообщить("У вас недостаточно прав для редактирования номенклатуры!");
Отказ = Истина;
КонецЕсли;
Важно: этот метод чувствителен к имени роли, заданному в конфигураторе (не к синониму). Если вы переименуете роль, код придется переписывать. Рассмотрим ситуацию, когда у пользователя есть "Полные права". В 1С роль с установленным признаком "Администрирование" или "Полные права" автоматически дает доступ ко всем объектам, игнорируя программные проверки, если они не прописаны жестко в коде модуля.
Если нам необходимо проверить наличие роли не у текущего пользователя, а у другого сотрудника (например, при выборе его из справочника Пользователи), метод РольДоступна не подойдет. В этом случае нам нужно обратиться к коллекции ПользователиИнформационнойБазы.
Проанализируем алгоритм действий: нам нужно сопоставить ссылку из справочника с пользователем информационной базы (ИБ). Обычно для этого используется реквизит ИдентификаторПользователяИБ.
// Получаем пользователя ИБ по его уникальному идентификатору
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатору(ПользовательСсылка.ИдентификаторПользователяИБ);
Если ПользовательИБ <> Неопределено Тогда
// Проверяем наличие роли в коллекции
Если ПользовательИБ.Роли.Содержит(Метаданные.Роли.НужнаяРоль) Тогда
// Роль найдена
КонецЕсли;
КонецЕсли;
Рассмотрим нюанс производительности: обращение к объекту ПользователиИнформационнойБазы работает медленнее, чем обычный запрос к базе данных, так как платформа обращается к служебным таблицам. Если вам нужно проверить роли для списка пользователей, старайтесь избегать этого метода внутри цикла.
В современных конфигурациях (УТ 11, КА 2, ERP, БП 3.0) реализован мощный механизм управления доступом. Рассмотрим функцию УправлениеДоступом.ЕстьРоль, которая является стандартом для разработчиков.
Преимущество этого метода заключается в том, что он учитывает не только прямые назначения ролей, но и права, полученные через профили и группы доступа. Пример вызова:
Результат = УправлениеДоступом.ЕстьРоль("ПолныеПрава", ПользовательСсылка);
Однако при использовании функций БСП часто возникает ошибка: "Недостаточно прав для работы с таблицей Справочник.ГруппыДоступа". Это происходит даже при установке привилегированного режима. Разберем причину этой ситуации:
УстановитьПривилегированныйРежим(Истина) эффективно работает только на стороне сервера. Если вы вызываете проверку на клиенте, режим не включится.Для решения этой проблемы убедитесь, что код выполняется в серверном модуле с установленным флагом Привилегированный.
Вместо того чтобы прописывать проверки в коде для каждого объекта, правильнее использовать механизм RLS (Record Level Security). Это позволяет ограничить доступ к конкретным элементам справочников или документов на уровне самой платформы.
Выясним, как настроить это в типовых решениях (например, в Комплексной автоматизации):
Важное ограничение: механизмы RLS не работают для пользователей с ролью "Полные права". Если администратору нужно запретить редактирование номенклатуры, единственный путь — программная проверка в модуле объекта в процедуре ПередЗаписью.
Часто разработчики ищут конкретную роль, но на самом деле им нужно проверить наличие права на действие. Рассмотрим функцию ПравоДоступа. Это более гибкий подход, так как право на изменение может быть включено в десяток разных ролей.
Если ПравоДоступа("Изменение", Метаданные.Справочники.Номенклатура, ПользовательСсылка) Тогда
// Пользователь может менять номенклатуру, независимо от того, как называется его роль
КонецЕсли;
Этот метод позволяет абстрагироваться от названий ролей и проверять реальные полномочия пользователя в системе.
Если проверка прав требуется часто (например, при каждом открытии формы или записи документа), постоянные вызовы РольДоступна или запросы к БСП могут замедлить работу. Проанализируем способ ускорения через Параметры сеанса.
При старте системы (в модуле сеанса) один раз вычисляются все критически важные права и записываются в параметры сеанса. В дальнейшем проверка сводится к простому обращению к переменной:
Если ПараметрыСеанса.ЗапрещеноРедактироватьСправочники Тогда
Отказ = Истина;
КонецЕсли;
Такой подход считается наиболее профессиональным в высоконагруженных системах, так как минимизирует количество обращений к метаданным и таблицам прав доступа.
Подведем итоги нашего анализа:
РольДоступна.УправлениеДоступом.ЕстьРоль на сервере.Выбор метода зависит от архитектуры вашей конфигурации и конкретной бизнес-задачи. Рассмотренные примеры кода помогут вам реализовать надежную систему контроля доступа.