В практике разработки на платформе 1С:Предприятие часто возникают ситуации, когда пользователю необходимо предоставить широкие права для работы через внешние системы (например, через HTTP-сервисы, Web-сервисы или COM-соединение), но при этом полностью исключить возможность его входа в программу через обычный визуальный интерфейс (тонкий или толстый клиент). Ситуация осложняется, если у пользователя есть роль ПолныеПрава, которая традиционно открывает все двери.
В данной статье мы разберем несколько эффективных способов решения этой задачи: от стандартных настроек прав доступа до программного перехвата сеанса на самом раннем этапе запуска.
Самый гибкий и распространенный способ — это программная проверка прав в модуле управляемого приложения. Разберем, как это работает. Платформа предоставляет событие ПередНачаломРаботыСистемы, которое вызывается до открытия основного окна программы. Если в этом событии установить параметру Отказ значение Истина, сеанс будет немедленно завершен.
Рассмотрим пример кода, который нужно разместить в Модуле управляемого приложения:
Процедура ПередНачаломРаботыСистемы(Отказ)
// Проверяем, не является ли запуск фоновым заданием или внешним соединением
#Если Клиент Тогда
// Вызываем серверную функцию для проверки роли
Если ОбщийМодульСервер.ПользовательИмеетЗапрещеннуюРоль() Тогда
ТекстСообщения = "Интерактивный запуск для данной учетной записи запрещен.";
ПоказатьПредупреждение(, ТекстСообщения);
Отказ = Истина;
КонецЕсли;
#КонецЕсли
КонецПроцедуры
Обратите внимание, что проверку роли РольДоступна() лучше выполнять на стороне сервера, так как на клиенте состав доступных ролей может кэшироваться или быть ограниченным. В серверном модуле (например, ОбщийМодульСервер) функция будет выглядеть так:
Функция ПользовательИмеетЗапрещеннуюРоль() Экспорт
// Проверяем наличие специфической роли, которой запрещен вход
Возврат РольДоступна("ЗапретИнтерактивногоВхода");
КонецФункции
Проанализируем более «чистый» с точки зрения платформы метод. У каждого объекта Роль в дереве конфигурации есть список прав, применимых ко всей конфигурации в целом. Одно из таких прав — «Интерактивный запуск» (Interactive startup).
Если мы создадим специальную роль, в которой снята галочка «Интерактивный запуск», и назначим её пользователю, то платформа сама не даст ему войти. Однако здесь есть важный нюанс: права в 1С суммируются. Если у пользователя назначено две роли, и в одной запуск запрещен, а в другой (например, в «Полных правах») разрешен — пользователь сможет войти.
Поэтому данный метод эффективен только в двух случаях:
Если ваша конфигурация разработана на базе БСП, мы можем использовать встроенные механизмы управления доступом. В современных версиях БСП проверка запуска часто интегрирована в общий процесс инициализации системы. Рассмотрим, как это реализовано в процедуре СтандартныеПодсистемыКлиент.ПередНачаломРаботыСистемы.
В этом случае разработчики часто используют «Профили групп доступа». Вы можете создать профиль, в котором будут разрешены только те виды соединений, которые необходимы пользователю. В интерфейсе «Администрирование — Настройки пользователей и прав» для группы доступа можно указать разрешенные типы клиентов (например, разрешить только «Внешнее соединение»).
Для программной реализации в рамках БСП часто используется следующий подход в процедуре ПередНачаломРаботыСистемы:
// В модуле управляемого приложения
Процедура ПередНачаломРаботыСистемы(Отказ)
ПараметрыСистемы = Новый Структура;
ПараметрыСистемы.Вставить("Отказ", Ложь);
// Вызов стандартной подсистемы
СтандартныеПодсистемыКлиент.ПередНачаломРаботыСистемы(ПараметрыСистемы);
// Собственная проверка
Если ПользователиИнформационнойБазы.ТекущийПользователь().Роли.Содержит(Метаданные.Роли.ТолькоДляСервисов) Тогда
Отказ = Истина;
Возврат;
КонецЕсли;
Отказ = ПараметрыСистемы.Отказ;
КонецПроцедуры
Выясним, существует ли еще более ранний этап проверки. Да, это событие УстановкаПараметровСеанса в Модуле сеанса. Это событие происходит на сервере еще до того, как начнет исполняться клиентский код модуля приложения.
Хотя в модуле сеанса нельзя напрямую вызвать Отказ = Истина (там нет такого параметра), мы можем вызвать исключение ВызватьИсключение. Это приведет к аварийному завершению попытки запуска для клиента.
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
// Проверяем тип соединения
Если СеансИнформационнойБазы.ПолучитьТекущийСеанс().ИмяПриложения = "1CV8" Тогда // Тонкий/толстый клиент
Если РольДоступна("СпецРольБезПраваВхода") Тогда
ЗаписьЖурналаРегистрации("Доступ.ПопыткаВхода", УровеньЖурналаРегистрации.Предупреждение, , , "Попытка интерактивного входа запрещена.");
ВызватьИсключение "Доступ к интерактивному интерфейсу запрещен для данной роли.";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Разберем типичную проблему: пользователь с административными правами. Если пользователю в конфигураторе назначено право Администрирование, никакие программные запреты внутри 1С не будут для него абсолютной преградой. Обладая правами администратора системы, такой пользователь может:
Поэтому, если ваша задача — запретить запуск именно для полных прав, убедитесь, что вы разделяете понятие роли ПолныеПрава (доступ к данным) и административных прав (доступ к метаданным и управлению пользователями в конфигураторе).
Проанализируем также необходимость логирования. Всегда сопровождайте программный отказ от запуска записью в Журнал регистрации. Это поможет системным администраторам быстро понять, почему «1С просто закрывается при запуске», не гадая, произошла ли это системная ошибка или сработал ваш защитный код.
Резюме: Для большинства задач оптимальным решением является использование события ПередНачаломРаботыСистемы в сочетании с серверной проверкой роли. Это позволяет выдать пользователю понятное сообщение и корректно завершить работу приложения.