Перейти к содержанию

Gerege Kiosk

Production · Слой 4 — Отраслевой продукт · Репозиторий: gerege-kiosk-mn · geregekiosk.mn

Единая платформа терминалов самообслуживания — на базе eID, усиленная ИИ. Она связывает терминал, стоящий в общественном месте, с цифровым удостоверением и позволяет гражданину получить справку, оплатить и распечатать документ, не стоя в очереди и не встречаясь с сотрудником. Круглосуточно, независимо от рабочего времени.

Владение

Платформой владеет и управляет Gerege Kiosk ХХК. Исходный код находится в закрытом репозитории и построен на общей основе open-gerege-core от Gerege Systems.

На geregekiosk.mn теперь работает Gerege Nexus

Проверено 2026-08-07: https://geregekiosk.mn/ отдаёт развёртывание Gerege Nexus — заголовок страницы «Gerege Nexus», описание тоже от Nexus. У домена свой действительный сертификат, хост — 38.180.243.183.

Поэтому поведение gerege-kiosk-mn, описанное на этой странице, может уже не совпадать с тем, что отдаёт публичный домен. Сверяйте версию, работающую на терминале, с этим развёртыванием.

Главная идея — тонкое приложение, толстая основа

Go-бэкенд Kiosk — это один файл. Аутентификация, RBAC, API-шлюз, конвейер ИИ, eID/SSO — все базовые возможности лежат в модуле github.com/gerege-systems/open-gerege-core; этот репозиторий подтягивает его по версии и запускает под своим именем:

func main() {
    server.ServiceName = "gerege-kiosk"

    app, err := server.NewApp()
    if err != nil { /* … */ }

    // Собственные маршруты приложения добавляются здесь:
    //   app.Router().Route("/api/xxx", xxx.Routes(app.Pool()))

    if err := app.Run(); err != nil { /* … */ }
}

Это решение технического долга от синхронизации форков, о котором говорится на странице Template Platform: раньше базовый код копировался в каждый репозиторий, и каждое улучшение приходилось переносить вручную. Теперь Kiosk — версионированный потребитель open-gerege-core: исправления по безопасности расходятся из одной точки, а обновление сводится к одной команде go get open-gerege-core@latest.

Слой Где живёт Кто владеет
Базовый бэкенд (аутентификация, RBAC, ИИ, шлюз, миграции) модуль open-gerege-core Gerege Systems
Точка запуска, бренд, настройки gerege-kiosk-mn/backend Gerege Kiosk ХХК
Frontend BFF, UI gerege-kiosk-mn/frontend Gerege Kiosk ХХК
Развёртывание, edge vhost gerege-kiosk-mn/deploy Gerege Kiosk ХХК

Структура

gerege-kiosk-mn/
├── backend/     # Go · тонкий потребитель open-gerege-core (cmd/api/main.go)
├── frontend/    # Next.js 15 BFF — Node 20, TanStack Query, mn/en/zh/ru
├── ios/         # Референсный клиент на SwiftUI (общается только через BFF)
└── deploy/      # compose, vhost для edge nginx, TLS-сертификат внутренней БД

Базовый бэкенд следует Clean Architecture — handler → usecase → repository → domain, без обратных импортов и без ORM (SQL вручную поверх pgx).

Аутентификация — только Gerege SSO

На экране входа одна кнопка: Войти через Gerege SSO. Паролей, регистрации по email/OTP и прямого потока eID нет.

graph LR
    C["Гражданин / терминал"] --> W["geregekiosk.mn<br/>Next.js BFF"]
    W --> A["Kiosk API"]
    A --> S["sso.gerege.mn<br/>Gerege SSO"]
    S --> E["eID Mongolia"]
    S -.->|"eID proxy"| A
  • Поток OIDC RP — /api/auth/sso/start → sso.gerege.mn → /sso/callback. Для мобильных приложений предусмотрен отдельный поток публичного клиента с PKCE (native).
  • Сессия — JWT access + refresh, refresh ротируется; logout аннулирует refresh и вносит access в deny-list.
  • Токен не попадает в браузер — только внутри httpOnly cookie, всё идёт через BFF.

Почему Kiosk не является eID RP сам?

По правилу границ №2 приложения слоёв 3–4 не обращаются к eID напрямую. Kiosk не владеет credential'ами eID RP — всё взаимодействие с eID идёт через Gerege SSO. Так учётные данные держатся в одном месте, а цепочка аудита не разрывается.

Профиль eID PKI — через прокси

Панель PKI вошедшего гражданина запрашивается через eID-прокси SSO. Kiosk обращается с access token пользователя, а SSO получает данные, используя свои собственные eID-учётные данные.

Что Где видно
Сводка /me/eid/id
Сертификаты и статус /me/eid/certificates
Связанные устройства /me/eid/devices
История аутентификаций/подписей /me/eid/logs
Связанные организации и уполномоченные подписанты /me/organizations

Случай, когда прокси выключен (на SSO неактивен сервис eid-proxy) или токен стал недействителен, UI обрабатывает отдельно — а не отдаёт 5xx.

Собственный провайдер OIDC

Kiosk может быть одновременно relying party для SSO и собственным провайдером идентичности. Когда заданы OAUTH_ISSUER и state key, включается собственный OAuth2/OIDC-провайдер на Go (без Ory Hydra):

  • экраны login · consent · logout под /oauth,
  • регистрация RP в таблице oauth_clients, ротация секретов,
  • пропуск consent для клиентов первой стороны и запоминание согласия,
  • discovery, userinfo, id_token — ключ подписи хранится в зашифрованном виде.

Благодаря этому небольшие приложения вокруг Kiosk могут предлагать «Sign in with Gerege Kiosk».

Поверхность, обращённая к гражданину

Раздел Что делает
/me/dashboard Личная панель
/me/services · /me/applications Каталог услуг, заявки и их ход
/me/references Справки
/me/notifications Уведомления
/me/payments Платежи
/me/appointments Запись на приём
/me/organizations Организации, членство, права
/me/eid/sign Электронная подпись документа
/me/integrations Сторонние подключения и Gerege Space
/me/ai · /me/translate ИИ-помощник, перевод на лету

При создании и поиске организации справка берётся из государственного реестра через Gerege Verify. Данные организаций защищены Postgres RLS для каждого пользователя.

Единый реестр услуг

Компонент R1 из Ring System — паспорт услуги и управление доказательствами:

  • каталог услуг, версии, публикация/архивирование,
  • жизненные события (life events) — группировка услуг по обстоятельствам гражданина,
  • доказательства (evidences) и панель once-only, измеряющая, насколько соблюдается принцип «не запрашивать повторно уже полученные документы».

Права двухуровневые: registry.view (чтение) и registry.manage (запись).

API Gateway

Управляемый из админки каталог сервисов: services · routes · consumers · API key · policy, плюс телеметрия запросов (overview + logs).

Текущий охват

Шлюз пока представляет собой слой управления и телеметрии. Работа по фактическому применению настроенных route/policy в качестве реального reverse-proxy (rate-limit и квоты на уровне consumer) стоит в плане.

Электронная подпись и sign relay

  • PAdES — подпись PDF со стороны сервера через интерфейс /v3 eID Mongolia; с постоянным сертификатом Document-Signer (в production — fail-closed).
  • Sign relay — шлюз, позволяющий сторонним RP подписывать через eID-учётные данные платформы. Этот маршрут идёт не через web BFF, а напрямую с edge в API (loopback-порт). О результате сообщает webhook.

Разницу между личной подписью гражданина с PIN2 и системной подписью Document-Signer см. на странице G-Sign.

ИИ-помощник (Gemini)

Конвейер на REST-клиенте без SDK:

Возможность Пояснение
Чат Текстовые и голосовые сообщения, function calling
STT Речь → текст
TTS Текст → речь (PCM→WAV)
Перевод Потоковый перевод на лету

Трёхслойный system prompt: жёстко заданные в коде guardrail'ы плюс область и инструкции, настраиваемые администратором через БД. Слой guardrail не настраивается никогда.

Инструмент search_knowledge заземляет ответ на реальные данные базы знаний. Поиск семантический — embedding от Gemini + косинусная близость на pgvector, с откатом к ILIKE при неудаче.

При временном сбое Gemini чат не отдаёт 5xx, а возвращает ответ о деградации (degraded: true) на языке пользователя. Маршруты /ai/* ограничены примерно 20 запросами в минуту на IP.

Интеграции и хранение

  • Сторонние OAuth-подключения — Google Drive · Google Meet · Dropbox. Токены хранятся зашифрованными по AES-256-GCM; если credential не настроен, соответствующая карточка отображается неактивной со статусом «Скоро».
  • Gerege Space — собственное SFTP-хранилище приложения с квотой на каждого пользователя. Host key SFTP проверяется (в production обязательно — иначе fail-closed).

Права, управление, аудит

  • RBAC — динамические роли и каталог прав, четырёхуровневая модель (superadmin → admin → manager → user).
  • Super admin — отдельная учётная запись, onboarding с MFA (allow-list приглашений → Google → eID → OTP по почте → TOTP + коды восстановления). Хранится в отдельной таблице, поэтому один человек может быть и админом по eID, и super admin.
  • Audit log — связанный хеш-цепочкой, только на добавление; с чтением для админа и endpoint'ом проверки целостности.
  • Security events — приём событий и панель мониторинга.
  • Внешний вид сайта — настраиваемые администратором accent / font / density / theme, плюс переопределение для каждого пользователя.

Безопасность

Контроль Реализация
Изоляция данных Postgres RLS (ENABLE + FORCE); api подключается ролью не superuser, на старте проверяется, что политика применяется
Сессия httpOnly cookie, токен никогда не попадает в клиентский JS
CSRF Двойная защита — специальный заголовок + проверка origin (на всех мутирующих маршрутах BFF)
Заголовки CSP · HSTS · COOP/COEP/CORP, allow-list CORS
Ограничение частоты Вход ~5 запросов/мин (cap тела 4 KiB), приложение 50 r/s, /ai/* ~20/мин
Подключение к БД В production sslmode=verify-full — TLS с внутренним CA
Endpoint'ы наблюдения В production /metrics и /swagger закрыты bearer-токеном
Доверие к прокси Если TRUSTED_PROXIES не задан, X-Forwarded-For не считается доверенным (защита от подделки rate-limit/аудита)

Общие требования экосистемы — на странице Безопасность.

Наблюдаемость

Трассировка OpenTelemetry + метрики Prometheus + структурированные логи Zap. В телеметрии сервис виден под именем gerege-kiosk.

Развёртывание

Стек Docker Compose: db (Postgres 16 + pgvector) · redis · migrate (разовый) · api · web. Браузер обращается только к web; api/db/redis остаются во внутренней сети и не открывают публичных портов.

Три решения по деплою достойны внимания:

  1. Миграция — отдельный шаг, а не часть up -d. Раньше при каждом повторном запуске migrate пересоздавались api и web, и даже коммит, не затрагивающий код, давал секундный 502.
  2. Если ничего не изменилось — вообще ничего не делать. Сборка Docker не воспроизводима, поэтому даже из одного кода получается новый image ID. Поэтому при неизменившемся HEAD деплой пропускается целиком.
  3. Сервисы данных не собираются при каждом деплое — пересоздание db рвёт все активные подключения к базе.

Vhost для edge nginx принадлежит этому репозиторию: при каждом деплое он устанавливается в conf.d, проверяется nginx -t и применяется reload'ом; если проверка падает, возвращается прежняя конфигурация. Это та же модель, что у docs.gerege.mn, Developer Portal и Template Platform.

Языки

Интерфейс и документация на четырёх языках: Монгол · English · 中文 · Русский. Полноту словарей фронтенда обеспечивает тест — если ключ отсутствует в каком-либо языке, CI падает.

Текущее состояние

Production Работает на geregekiosk.mn. Возможности базовой платформы унаследованы полностью; специфические для терминалов потоки продолжают добавляться.

Следующие шаги: фактическое применение правил шлюзом, потоковые (SSE) ответы в чате, CSP на основе nonce, автоматическое резервное копирование БД и тест восстановления, окружение staging.

Связанные страницы