Add demo UI showcase mode
This commit is contained in:
@@ -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.
|
||||
@@ -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) пишет только затронутое сообщение
|
||||
|
||||
@@ -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+
|
||||
|
||||
Reference in New Issue
Block a user