docs: профиль клиента — контракт bj и сторона сервера лицензий (для Вадима)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XG3zNMMf2LMoDpXo22mwMX
2026-10-16 09:59:55 +03:00
parent 13832fefad
commit c58465e7c8
1 changed files with 50 additions and 0 deletions
@@ -0,0 +1,50 @@
+# Профиль клиента: предзаполнение мастера настройки под клиента
+
+Цель: при подключении клиента часть настроек отличается от стандарта (коды НРД, базы
+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)
+
+```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`) — поведение мастера как раньше.