При работе с информационными базами 1С часто возникает необходимость защитить систему от выполнения нежелательных действий в тестовых средах. Например, если вы развернули копию рабочей базы для разработки или тестирования, крайне важно, чтобы она автоматически не начала рассылать реальные SMS клиентам, не выгружала данные в учетные системы государственных органов или не синхронизировалась с интернет-магазином. В рамках данной статьи мы разберем универсальные способы идентификации "тестовости" базы, проанализируем механизмы БСП и рассмотрим варианты реализации собственной защиты.
Если ваша конфигурация построена на базе БСП, то задача определения копии уже решена разработчиками фирмы «1С». Рассмотрим подробнее, как работает этот механизм. БСП хранит текущую строку соединения с информационной базой в специальном регистре сведений ПараметрыИнформационнойБазы. При каждом старте системы или выполнении регламентных заданий код сравнивает текущую строку соединения, полученную функцией СтрокаСоединенияИнформационнойБазы(), со значением, сохраненным ранее.
Если строки не совпадают, система понимает, что база была перемещена или восстановлена из бэкапа под другим именем. В этом случае при запуске пользователем интерактивного сеанса выдается предупреждение. Если пользователь подтверждает, что база является копией, система устанавливает флаг блокировки регламентных заданий на уровне кода конфигурации.
Разберем, как это выглядит в Журнале регистрации при попытке выполнения регламентного задания в копии без подтверждения перемещения:
Ошибка РЗ Отправка СМС: "{ОбщийМодуль.РегламентныеЗаданияСлужебный.Модуль(175)}:
Изменилась строка соединения информационной базы.
Возможно информационная база была перемещена.
Регламентное задание "Отправка SMS" отключено.
ВызватьИсключение СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(НСтр("ru = 'Изменилась строка соединения информационной базы."));
Таким образом, использование БСП — это наиболее надежный и современный метод. Система автоматически «гасит» потенциально опасные фоновые процессы до тех пор, пока администратор не примет осознанное решение.
В случае, если вы работаете с самописной конфигурацией ("нетленкой") без БСП, можно реализовать аналогичный алгоритм самостоятельно. Идея заключается в создании константы, в которой будет храниться "правильный" адрес рабочей базы. Проанализируем реализацию такого метода.
Шаг 1. Создадим константу АдресРабочейБазы (тип Строка). При первом запуске в промышленной среде запишем туда текущую строку соединения.
Шаг 2. В модуле управляемого приложения или в модуле сеанса создадим функцию для проверки. Рассмотрим пример кода:
Функция ЭтоТестоваяБаза() Экспорт
ТекущаяСтрока = ВРег(СтрокаСоединенияИнформационнойБазы());
ЭталоннаяСтрока = ВРег(Константы.АдресРабочейБазы.Получить());
// Если константа пуста, считаем базу рабочей и заполняем её (опционально)
Если ПустаяСтрока(ЭталоннаяСтрока) Тогда
Возврат Ложь;
КонецЕсли;
Возврат ТекущаяСтрока <> ЭталоннаяСтрока;
КонецФункции
Важный нюанс: при сравнении строк соединения в клиент-серверном варианте нужно учитывать, что имя сервера может быть прописано как по IP-адресу, так и по сетевому имени или FQDN. Поэтому рекомендуется использовать функцию ВРег() для приведения к верхнему регистру и, при необходимости, парсить строку, выделяя только ключевые параметры (имя сервера и имя базы).
Иногда проверки только строки соединения недостаточно, так как администратор может создать алиас сервера или прописать редирект на уровне файла hosts. Выясним причину, по которой стоит использовать дополнительные параметры сервера.
Для более жесткой привязки можно использовать проверку имени компьютера, на котором запущен сервер 1С. Рассмотрим вариант проверки через константу с именем сервера:
Если ИмяКомпьютера() <> Константы.ИмяРабочегоСервера.Получить() Тогда
// Мы явно не на "боевом" сервере
Константа.ЭтоТестоваяБаза = Истина;
КонецЕсли;
Этот метод хорош тем, что при простом копировании файла базы данных (в файловом варианте) или восстановлении SQL-бэкапа на другом физическом сервере, проверка сработает мгновенно. Однако помните, что на одном сервере 1С может крутиться несколько баз (рабочая и тестовая), поэтому проверку имени сервера всегда нужно комбинировать с проверкой имени самой базы в кластере.
В новых версиях платформы 1С реализованы методы, упрощающие жизнь разработчику. Проанализируем использование метода ПолучитьПараметрыСоединенияИнформационнойБазы(). Этот метод возвращает структуру, которая уже содержит разобранные части адреса:
Используя эти свойства, мы можем избежать ошибок ручного парсинга строки соединения, когда в ней встречаются лишние кавычки или параметры авторизации.
Интересный способ — проверка наличия специального файла-маркера на диске сервера. Рассмотрим ситуацию: на рабочем сервере в папке C:\1C_Prod_Marker\ лежит пустой файл production.txt. В коде 1С мы проверяем его наличие:
ФайлМаркер = Новый Файл("C:\1C_Prod_Marker\production.txt");
Если Не ФайлМаркер.Существует() Тогда
// Файла нет — значит это копия на другом сервере или локальный ПК разработчика
БлокироватьОпасныеДействия();
КонецЕсли;
Преимущество этого метода в том, что файл не попадает в SQL-бэкап или выгрузку DT, а значит, он никогда не "переедет" в тестовую среду вместе с данными. Это гарантирует, что любая копия, развернутая вне рабочего сервера, сразу определит себя как тестовая.
Просто определить, что база тестовая — мало. Нужно остановить выполнение регламентных заданий. Рассмотрим, как это сделать правильно:
ЭтоТестоваяБаза(). Если база копия — прерывать выполнение.Подводя итог, можно сказать, что наиболее универсальным и рекомендуемым способом является сравнение текущих параметров соединения (сервер + имя базы) с эталонными значениями, хранящимися в константах, при обязательном использовании механизмов БСП, если они доступны в вашей конфигурации. Это обеспечит надежную защиту ваших данных и предотвратит нештатные ситуации при работе в тестовых контурах.