Add demo UI showcase mode

2026-04-12 09:58:32 +03:00
parent dd08427424
commit d7e9d90453
6 changed files with 325 additions and 33 deletions
@@ -238,6 +238,49 @@

 Проблема 64KB+ payload у shared-sqs оказалась не багом Go-сервиса и не проблемой Redis/persistence, а ограничением ingress path в кластере штурвала: объект ingress у приложения настроен корректно, часть аннотаций применяется, но именно `proxy-request-buffering` platform controller в итоговый nginx.conf не прокидывает, при этом upstream ingress-nginx такую аннотацию поддерживает. Поэтому вводить hard-limit 32KB в коде я считаю неправильным; правильное практическое решение на текущий момент — оставить сервис без искусственного code-level ограничения, а 32KB считать безопасным эксплуатационным размером и документировать это как известную особенность инфраструктуры.

+---
+# Agent: GitHub Copilot (GPT-5.4)
+
+## Задача: дать обычному demo-пользователю понятный вход в UI без личного Nubes JWT
+
+### Контекст
+После переработки публичного showcase-репозитория осталась продуктовая дыра: AWS CLI уже имел публичные demo credentials, а UI по-прежнему требовал личный nubes JWT. Для обычного пользователя это ломало демо-сценарий: CLI можно попробовать сразу, а UI нет.
+
+### Локальная гипотеза
+Если в коде уже существует сидированный demo tenant с фиксированными AWS credentials, то самый дешёвый и чистый путь — не придумывать новую сущность, а добавить отдельный UI demo token, который логинит ровно в этот tenant. Тогда CLI и UI будут опираться на один и тот же демонстрационный контур.
+
+### Что проверил перед правкой
+1. В `app/admin/admin.go` единственный публичный UI login endpoint `POST /ui/api/auth` принимал только JWT, парсил claims и всегда вызывал `PingNubesAPI`.
+2. В `app/ui/index.html` логин-форма явно требовала `API Token (nubes JWT)`.
+3. В `app/cmd/seed.go` уже существует seeded demo tenant:
+   - tenant ID: `t-demo-shared-sqs-ngcloud`
+   - access key: `SSAK-demo-shared-sqs`
+   - secret key: `demo-secret-key-shared-sqs-ngcloud-2026`
+4. Дополнительно нашёл соседний дефект: UI routes переиспользовали admin handlers и `GET /ui/api/tenants` возвращал весь список tenant-ов, а `/ui/api/health` показывал глобальные счётчики сервиса. Для demo-login это недопустимо.
+
+### Решение
+Сделал один узкий срез:
+1. Добавил публичный UI demo token `demo-ui-shared-sqs-ngcloud-2026` с возможностью переопределения через env.
+2. Привязал его к уже существующему seeded demo tenant.
+3. Оставил существующий JWT flow без изменения для реальных пользователей.
+4. Начал класть авторизованный UI tenant в request context.
+5. Ограничил UI API текущим tenant-ом:
+   - `GET /ui/api/tenants` возвращает только своего tenant-а;
+   - `GET /ui/api/health` считает только свои очереди и сообщения;
+   - создание и удаление tenant-а через UI запрещены.
+6. Обновил встроенный UI: форма логина теперь прямо подсказывает demo token и больше не выглядит как админская панель для управления всеми tenant-ами.
+
+### Почему именно так
+- Это минимальное изменение с хорошим ROI: один новый demo token закрывает UX-проблему без нового storage, без нового auth-service и без изменения AWS credentials.
+- Demo-пользователь теперь видит только demo tenant и не получает случайный обзор всей системы.
+- CLI и UI сходятся на одной и той же demo-учётке, то есть продуктовая история становится понятной.
+
+### Что сознательно НЕ делал
+- Не убирал JWT flow.
+- Не строил отдельную demo role model.
+- Не менял SQS auth path для AWS CLI.
+- Не пытался превращать UI в полноценную admin console и пользовательскую console одновременно: для UI выбрал явный user/demo режим с одним tenant-ом.
+
 ---

 ## Внешние ссылки для возврата к теме 64KB+