Каталог решений - Простейший механизм «Дополнительных настроек» или почему хранить пароли, ключи API и другие параметры в коде — плохо?

Простейший механизм «Дополнительных настроек» или почему хранить пароли, ключи API и другие параметры в коде — плохо?

Простейший механизм «Дополнительных настроек» или почему хранить пароли, ключи API и другие параметры в коде — плохо?

В наличии

Представьте ситуацию: вы пишете обработку для отправки email-уведомлений клиентам. Чтобы подключиться к серверу почты, вам нужны: логин, пароль, SMTP-адрес. Что делает большинство программистов?

Категория:

Описание

Просто пишут:

Логин = "admin@example.com";
Пароль = "secret123";
SMTPАдрес = "smtp.example.com";

Звучит разумно?

На первый взгляд — да.

Но на самом деле — это как оставить ключ от квартиры на видном месте.

 

Что может пойти не так?

  1. Изменение одного параметра требует правки кода

Представь, что нужно сменить пароль от почты или адрес SMS-сервиса.

Что ты делаешь?

Входишь в конфигуратор → ищешь нужный модуль → меняешь строку → сохраняешь → перезаливаешь обработку.

Если таких мест несколько (а они есть!), то приходится:

  • искать по всем модулям,
  • бояться сломать что-то ещё,
  • тестировать после каждой замены.
  1. Такие параметры часто дублируются в разных местах

Вот типичная ситуация:

В одном модуле используется SMTPАдрес = "smtp.example.com";

Во втором — СерверПочты = "smtp.example.com";

В третьем — "mail.example.com"

Один и тот же параметр, но написан по-разному и в разных местах.

И если сервер меняется… начинается кошмар поддержки.

  1. Это опасно с точки зрения безопасности

Когда ты хранишь:

  • пароли,
  • токены API,
  • логины,

прямо в коде, ты рискуешь:

  • Утечкой данных : коллега, партнёр или даже бывший сотрудник получает доступ.
  • Юридическими последствиями : особенно если вы работаете с персональными данными или платёжными системами.

 

Пример из жизни

Ситуация:

Вы интегрируете 1С с SMS-сервисом. Пишете:

APIКлюч = "abc123xyz";

Проходит полгода. Ключ утек. Или просто истёк. Нужно поменять.

Что происходит?

Вы открываете конфигурацию.

Ищете все места, где встречается APIКлюч.

Меняете значение.

Тестируете каждую точку, чтобы ничего не сломалось.

А если этот ключ использовался:

  • в внешней обработке,
  • в расширении,

— тогда вы потратите часы, чтобы всё найти и исправить и протестировать.

 

А теперь представь, как можно было сделать правильно

Вместо этого:

APIКлюч = "abc123xyz";

Сделай так:

APIКлюч = Настройки.ЗначениеНастройки("КлючАПИ");

Где ЗначениеНастройки () берёт данные из таблицы с общими настройками, список которых можно расширять в пользовательском режиме:

Теперь, чтобы изменить ключ — достаточно обновить одну точку.

Никаких поисков, никакого редактирования кода.

 

Ещё примеры из реальной жизни

Ссылки на элементы справочников или документы

НужныйКонтрагент = Справочник.Контрагенты.НайтиПоКоду("001");
Молоко = Справочник.Номенклатура.НайтиПоНаименованию("Молоко");
ЭталонныйДокумент = Документ.РеализацияТоваров.НайтиПоНомеру("1001");

Хороший вариант:

НужныйКонтрагент = Настройки.ЗначениеНастройки("НужныйКонтрагент");
Молоко = Настройки.ЗначениеНастройки("Молоко");
ЭталонныйДокумент = Настройки.ЗначениеНастройки("ЭталонныйДокумент");

В видео ниже я создаю расширение, которое решает проблемы с хранением настроек в коде. Данный пример можно легко адаптировать под вашу конфигурацию.

Тестирование проводилось на релизах: 8.3.25.1501 (X32/x64), Управление торговлей, редакция 11 (11.5.12.167). Однако должно работать на любой конфигурации, возможно нужно будет исправить режим совместимости, в случае использования более старых версий конфигураций. 

has been added to your cart:
Оформление заказа