Bridge-and-Join-s/docs/client-profile.md

Профиль клиента: предзаполнение мастера настройки под клиента

Цель: при подключении клиента часть настроек отличается от стандарта (коды НРД, базы QUIK/DEPO, папки, реквизиты). Эти отличия храним у себя на сервере лицензий (lic), администратор правит их в портале под конкретного клиента, а установка клиента получает их и предзаполняет мастер настройки. Оператор на месте всё может поправить — профиль ничего не перетирает.

Сторона bj (реализовано, internal/lkgateway/client_profile.go)

• Страница /admin/setup/client-profile: «Скачать эталон» (текущая конфигурация стенда, секреты затёрты) и, для стенда, «Применить профиль» (вставить JSON).
• Профиль применяется:
  1. при старте — если рядом с setup.json лежит client-profile.json (локальный фолбэк);
  2. при активации/продлении ключа — из поля config_profile ответа сервера лицензий.
• Семантика — предзаполнять только пустые разделы: раздел настроек, который ещё не настроен (нулевой), заполняется из профиля; настроенный — не трогается. Разделы License, служебные поля и quik_export не заполняются никогда.

Формат профиля (JSON)

{
  "tenant": "ООО Ромашка",
  "note": "комментарий администратора",
  "saved_at": "2026-10-16T09:00:00Z",
  "settings": { "<подмножество разделов setup.json>": { ... } }
}

settings — то же дерево, что setup.json (разделы postgres, fancy_mssql, quik_mnp, nsd, lk, alerts, auth, work_hours, … — заполнять только нужные клиенту). Секреты (пароли, DSN, токены) в эталон не выгружаются — их заполняет администратор под клиента.

Сторона сервера лицензий (репозиторий zuevav/lic_Bridge-and-Join-s) — что сделать

1. Хранить на каждого tenant объект профиля (структура выше), редактируемый администратором в портале (раздел клиента). Отправная точка — «эталон», выгруженный из стенда (кнопка на странице выше), дальше администратор подстраивает отличия.
2. В ответы POST /v1/activate и POST /v1/renew добавить необязательное поле config_profile — тот же объект профиля этого tenant (или опустить, если профиля нет). bj его примет без доработок (поле config_profile в licenseReply, client_profile.go).
3. Формат токена/подписи не меняется — config_profile идёт рядом с token, вне подписанного токена лицензии.

Договорённости

• Канал доставки профиля — обычный ответ сервера лицензий (не через M2M-шлюз).
• Профиль не перетирает настроенное: безопасен при повторной активации/продлении.
• Нет профиля (ни файла, ни config_profile) — поведение мастера как раньше.