Для кого: разработчики 1С, DevOps, администраторы CI.
Учётные данные баз лежат в env.json вне Git, читаются из BSL штатным ЧтениеJSON, а для продакшена секреты передаются через хранилище CI. Код чтения и подключения через COMConnector прогнан на платформе 8.3.27.2130. Граница подхода: файл хранит пароль открытым текстом.
Пароль от базы в тексте обработки, строка подключения в модуле, логин и пароль в .bat-файле сборки. Такой код работает, пока не попадает в репозиторий, на тестовый стенд или к подрядчику. Дальше пароль живёт в истории Git, и удалить его оттуда сложнее, чем написать.
Простое решение: вынести параметры окружения в отдельный файл env.json, который лежит рядом с проектом, читается скриптами и кодом 1С и никогда не коммитится. В статье разберём структуру файла, чтение из BSL, правила для Git и права доступа, а также границы подхода.
📄 Что лежит в env.json
Файл описывает окружение: где находится база, под каким пользователем к ней подключаться, где установлена платформа. Один файл на одно окружение: разработка, тест, продакшен.
Секции разделяйте по назначению: доступ к информационной базе 1С отдельно, доступ к СУБД (если она нужна скриптам администрирования) отдельно. Так права и сроки смены паролей у них могут различаться, и разработчику, которому нужна только информационная база, не придётся видеть пароль СУБД.
💻 Чтение из кода 1С
Штатные средства платформы читают JSON без внешних компонентов:
Путь к файлу передайте параметром запуска или переменной среды. Жёстко прописанный путь в модуле возвращает исходную проблему: конфигурация привязана к одной машине.
Подключение к файловой или клиент-серверной базе через COM-соединение выглядит так:
Строка в connection в этом примере заканчивается точкой с запятой, поэтому параметры пользователя дописываются сразу. Проверьте формат строки на своей версии платформы: для клиент-серверной базы вместо File= указываются Srvr= и Ref=.
🌿 Правила для Git
- Добавьте
env.jsonв.gitignoreдо первого коммита проекта. Если файл уже попал в историю, смена пароля обязательна: чистка истории не поможет против тех, кто успел клонировать репозиторий. - Храните в репозитории шаблон
env.template.jsonс заглушками вместо паролей. Он описывает структуру, а разработчик копирует его вenv.jsonи заполняет. - Не используйте пароли рабочей базы на машинах разработчиков. Для разработки заведите отдельного пользователя базы с ограниченными правами.
Я прогнала обе функции - ПрочитатьОкружение и подключение через V83.COMConnector - на файловой базе под Windows, платформа 8.3.27.2130 (x86). Отсутствующий файл даёт исключение. Linux я не проверяла.
🔒 Права на файл
На Linux ограничьте доступ владельцу командой chmod 600 env.json. На Windows уберите из свойств файла группы «Все» и «Пользователи» и оставьте учётную запись, от имени которой работает сборка или служба.
🧭 Пути и окружения
Платформу и каталоги удобно держать в том же файле, а окружения разделять именами: env.dev.json, env.test.json, env.prod.json. Скрипт получает имя файла параметром. Проверка существования файла в начале работы (пример выше) выявляет неверный путь сразу, до запуска сборки.
🚧 Где подход заканчивается
env.json хранит пароль открытым текстом. Он защищает от попадания в Git и от случайного просмотра, но не от человека с доступом к серверу. Для продакшена используйте хранилище секретов вашего CI-сервера или менеджера секретов и передавайте значения в скрипт через переменные среды на время запуска. Что подойдёт, зависит от инфраструктуры: этот вопрос решает администратор, и универсального ответа здесь нет.
📋 Чек-лист
env.jsonв.gitignore, шаблон в репозитории.- Секции разделены: информационная база 1С отдельно от СУБД.
- Права на файл ограничены.
- Для каждого окружения свой файл и свой пользователь.
- Продакшен-пароли лежат в хранилище секретов.
- Путь к файлу передаётся параметром.
Вступайте в нашу телеграмм-группу Инфостарт