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