Add demo UI showcase mode

This commit is contained in:
Naeel
2026-04-12 09:58:32 +03:00
parent dd08427424
commit d7e9d90453
6 changed files with 325 additions and 33 deletions
@@ -0,0 +1,36 @@
# Решение: demo UI режим для showcase
Дата: 2026-04-12 09:57 MSK
Агент: GitHub Copilot (GPT-5.4)
## Контекст
Нужно показать заказчику два сценария на одном стенде:
1. Быстрый demo-вход без подготовки.
2. Реальный пользовательский вход по настоящему Nubes token.
До изменения UI принимал только реальный JWT и при этом использовал admin handlers слишком широко, из-за чего demo-сценарий был неудобным, а UI-поведение было ближе к admin console, чем к пользовательской витрине.
## Решение
Принят временный showcase-режим:
- добавить публичный UI demo token `demo-ui-shared-sqs-ngcloud-2026`;
- привязать его к уже существующему seeded demo tenant `t-demo-shared-sqs-ngcloud`;
- сохранить реальный JWT flow без изменений;
- ограничить UI API текущим tenant-ом;
- запретить создание и удаление tenant-а через UI.
## Почему так
- Это позволяет быстро показать сервис без подготовки аккаунта.
- Это сохраняет реальный пользовательский сценарий: заказчик может ввести настоящий token и попасть в свой tenant.
- Это убирает из demo UI лишний обзор всей системы и снижает риск случайной демонстрации чужих данных.
- Это минимальное изменение, которое можно позже убрать без ломки основной JWT-модели.
## Границы решения
- Решение предназначено для demo/showcase, не для production security model.
- В production demo token должен быть удалён вместе с seeded demo tenant.
- Основным постоянным сценарием остаётся вход по реальному Nubes JWT.
+9
View File
@@ -2,6 +2,15 @@
## Версия v0.1.x
### v0.1.22-dev (2026-04-12) — demo UI login + UI tenant scoping
- ✅ Добавлен публичный UI demo token: `demo-ui-shared-sqs-ngcloud-2026`
- ✅ Demo token маппится на уже сидированный demo tenant `t-demo-shared-sqs-ngcloud`
- ✅ UI API больше не показывает чужие tenant-ы: `GET /ui/api/tenants` возвращает только текущий tenant
- ✅ UI health для авторизованного пользователя считает только его очереди и сообщения
- ✅ Создание и удаление tenant-а через UI отключены, чтобы demo/login-console не выглядела как admin panel
- ✅ Узкая валидация: `go test ./app/admin` PASS
- ✅ Публичный showcase README синхронизирован с новым demo UI token
### v0.1.21 (2026-04-11) — Redis schema v2 + per-message persistence
- ✅ Redis schema v2: metadata в HASH `ssq:queues`, сообщения в отдельных HASH `ssq:msg:{queueKey}`
- ✅ Per-message persistence: каждая операция (send/receive/delete/visibility) пишет только затронутое сообщение
+43
View File
@@ -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+