Административный контур

Рабочее место команды, которая сопровождает платформу. Административный контур объединяет жалобы, поддержку, управление аккаунтами и компаниями, исполнение решений и аудит. Это отдельное приложение со своим Gateway, служебными сессиями и разрешениями. Его можно разместить во внутренней сети и открывать сотрудникам только через корпоративный VPN.

Демонстрационный вход — admin.geek.moscow; учётные записи приведены на странице доступов. На публичном стенде адрес открыт для демонстрации с обязательным входом. Закрытое размещение описано ниже как вариант корпоративной поставки.

Источники: бизнес-требования, 24, системные требования, 25, готовность архитектуры, 26, архитектура, 27, передача контрактов, 28, управление аккаунтами и компаниями, 30, Backoffice, Admin Gateway.

Результат для оператора

Оператор принимает жалобу в работу, изучает разрешённые материалы, принимает обоснованное решение и видит, применено ли оно в действительности. При ошибке интерфейс объясняет состояние исполнения и допустимость повтора. История позволяет восстановить, кто, когда, по какой причине и к какому объекту применил ограничение.

Принципиально различаются решение оператора и результат у владельца объекта. Закрытая жалоба с сохранённым решением ещё не означает, что аккаунт заблокирован или публикация скрыта.

Что можно делать через админку

В исходниках административного приложения предусмотрены семь основных разделов. Меню строится по правам сотрудника: специалист поддержки, модератор и администратор доступа получают разные рабочие инструменты. Ссылки ниже требуют служебного входа; доступность действий определяется полномочиями и версией развёрнутого приложения.

Раздел	Задачи сотрудника
Жалобы	Найти обращение по состоянию, взять его в работу, изучить разрешённые материалы, назначить ответственного, принять решение о публикации или аккаунте
Аккаунты	Искать пользователей, изучать тип и состояние аккаунта, проверять ограничения и сессии; с соответствующими правами — блокировать, отзывать сессии, ограничивать возможности, удалять или восстанавливать
Компании	Просматривать организацию, владельца, участников и приглашения; управлять членствами, передавать владение, применять ограничения и архивирование
Исполнение решений	Следить за применением решений, видеть ошибки и попытки исполнения, выполнять допустимый повтор и работать с пересмотром
Поддержка	Читать обращения, брать их в работу, фиксировать результат обработки и закрывать обращение
Аудит	Восстанавливать историю действий: кто, что и на каком основании изменил, как завершилось исполнение
Сотрудники и доступ	Просматривать операторов, выдавать и отзывать конкретные полномочия, применять наборы прав под рабочие обязанности

Из карточек доступны предметные действия над анкетами и вакансиями, включая модерацию публикаций. Полномочие на чтение карточки и право изменить объект проверяются отдельно. Необратимое стирание данных выделено в отдельное действие с отдельным разрешением и подтверждением.

Пример повседневной работы: модератор получает жалобу на вакансию, изучает её материалы, сохраняет мотивированное решение о скрытии, затем проверяет исполнение и запись аудита. Специалист поддержки помогает восстановить доступ, а сотрудник с правами управления компанией решает вопрос членства или передачи владения. Для этих задач не требуется прямое редактирование таблиц базы данных.

Состав

flowchart LR
    STAFF["Сотрудник"] --> UI["Admin UI"] --> GW["Gateway: admin"]
    GW --> ID["Identity: сессия и полномочия"]
    GW --> BO["Backoffice: жалобы, решения, исполнение"]
    USER["Пользователь"] --> PUBLIC["Gateway: public"]
    PUBLIC -->|"Жалоба или обращение"| BO
    BO -->|"Материалы и действия"| OWN["Сервисы — владельцы объектов"]
    BO -->|"Ограничение аккаунта"| ID

Admin UI — отдельная frontend-сборка с экранами сотрудников. Admin Gateway — общий код Gateway с GATEWAY_PROFILE=admin, отдельными разрешёнными маршрутами и RPC. Backoffice — самостоятельный сервис со своей базой backoffice: жалобы, назначения, материалы, решения, попытки исполнения, поддержка и аудит.

Backoffice не владеет паролями, профилями, вакансиями или разрешениями на раскрытие. Он подготавливает и фиксирует решение, управляет выполнением, запрашивает результат у предметного владельца. API, worker и издатель outbox Backoffice используют одну предметную модель.

Хосты и маршруты

Хост и путь	Назначение
Административный контур: `/auth/*`	CSRF, вход, обновление и завершение служебной сессии
Административный контур: `/api/v1/*`	Разрешённые административные операции через Admin Gateway
Остальные пути административного контура	Статическое Admin UI; неизвестные API-подобные пути получают JSON 404
Продуктовый контур: `/auth/`, `/api/v1/`	Продуктовые действия, в том числе отправка жалобы и обращения
Продуктовый контур: `/admin`, `/admin/`, `/api/v1/operator/`	Не обслуживаются как вход в административный контур; возвращается 404

Профили Gateway различаются cookie, audience, назначением сессии, идентичностью сервиса, лимитами, сетевыми настройками и разрешёнными маршрутами. Публичный профиль не регистрирует административные методы, административный не является универсальным прокси продуктового API. Доступ сотрудников к административному контуру предоставляется отдельно.

Админка во внутренней сети или за VPN

Отдельный хост и отдельный Admin Gateway позволяют ограничить административный контур на сетевом уровне. В корпоративной поставке сотрудник подключается к VPN, открывает внутренний адрес админки и проходит служебную авторизацию. Публичный продукт продолжает обслуживать инженеров и компании через собственный Gateway.

Для такого размещения нужно настроить внутренний ingress или reverse proxy, внутренний DNS и маршрутизацию через VPN. Доступ с внешней сети закрывается ко всему административному хосту: интерфейсу, /auth/* и /api/v1/*. Следует также исключить обход через другой публичный ingress, открытый сервис или адрес узла. Ограничение только видимости DNS-имени не заменяет сетевую изоляцию.

В манифесте внутреннего стенда infra/k3s/geek-admin/60-ingress.yaml уже есть ограничение источников по адресам tailnet и pod-сети. Для публичной демонстрации используется отдельная конфигурация. При переносе в корпоративную сеть список разрешённых источников и правила маршрутизации задаются под её устройство; при необходимости межсервисные соединения дополнительно ограничиваются NetworkPolicy.

VPN отвечает за возможность достучаться до приложения. Служебная сессия, права оператора и проверки каждого действия продолжают работать внутри сети. Для единого входа сотрудников можно дополнить этот вариант интеграцией с корпоративным Keycloak или другим OIDC-провайдером. Такая интеграция требует отдельного адаптера и настройки соответствия прав.

Служебные сессии и полномочия

Сотрудник использует аккаунт Identity, но получает refresh-семью назначения ADMIN и access JWT с aud=geek-admin-api. Продуктовый токен на административном хосте и административный на продуктовом отклоняются с AUDIENCE_REJECTED.

По действующим требованиям D-12 ADMIN-сессия проверяется на каждом вызове через основную БД Identity без положительного кэша. Для PRODUCT сохраняется локальная проверка JWT с ограниченным окном до 300 секунд; актуальные ограничения аккаунта и ресурсов проверяются отдельно. Это требование текущих контрактов, а не утверждение о повторной проверке всех развёрнутых компонентов.

Базовые разрешения: COMPLAINT_READ, COMPLAINT_REVIEW, PUBLICATION_HIDE, ACCOUNT_BLOCK. Расширение добавляет, в частности, ACCOUNT_READ и ACCOUNT_PII_READ; восемь версионируемых наборов полномочий разворачиваются в обычные выдачи прав.

Все восемь наборов — от наблюдателя аккаунтов до администратора доступа — и их назначение перечислены в ролевой модели. Она также объясняет отличие служебных прав от типа аккаунта, роли в компании и согласия инженера.

Чтение жалобы, просмотр её материалов и применение санкции — разные действия. Роль HR, владение компанией и тип продуктового аккаунта не дают служебных полномочий. Нераскрытые контакты, фотографии, приватные ссылки и переписка не должны отправляться в браузер скрытыми полями. Сервер возвращает допустимые действия и причины недоступности; интерфейс не вычисляет права только по статусу жалобы.

Жизненный цикл жалобы

Статус жалобы	Значение
`OPEN`	Рассмотрение ещё не началось
`REVIEWING`	Жалоба назначена сотруднику и рассматривается
`RESOLVED`	Решение сохранено; исполнение учитывается отдельно

Статус исполнения	Значение
`REQUESTED`	Выполнение решения ожидается
`APPLYING`	Проверяется или применяется ограничение
`APPLIED`	Владелец подтвердил результат; для отклонённой жалобы санкция не применяется
`REJECTED`	Решение не допущено к исполнению, причина известна
`FAILED`	Успешное завершение не подтверждено; возможность повтора зависит от причины

Причины жалобы: спам, выдача себя за другого, недопустимое содержимое, иная причина. Решения: DISMISS, HIDE_QUESTIONNAIRE, HIDE_VACANCY, BLOCK_ACCOUNT.

Очередь. Жалобы поступают из продукта, фильтруются по состоянию и типу объекта.
Назначение. Взятие в работу проверяет OPEN и ожидаемую версию, фиксирует сотрудника и аудит одной транзакцией.
Материалы. Сервис-владелец возвращает разрешённое представление анкеты или вакансии. Жалоба на аккаунт показывает контекст обращения, а не неограниченное досье.
Решение. Основание, цель и версия объекта сохраняются вместе с закрытием жалобы, операцией, первой попыткой исполнения и outbox.
Исполнение. Worker вызывает владельца. Тот проверяет применимость, исключает повтор по decision_id, применяет ограничение и записывает собственный аудит.
Подтверждение. Backoffice получает авторитетный результат. Временные ошибки повторяются с задержкой, окончательные останавливаются с причиной.
История. Сохраняется цепочка состояний, решений, попыток и участвовавших операторов.

Удалённый вызов не удерживает транзакцию БД и не создаёт общую транзакцию двух сервисов. Возможная задержка между решением и ограничением отражается в интерфейсе.

Управление аккаунтами и компаниями: EXT-07

Документ 30 описывает прямые действия, для которых входящая жалоба не обязательна:

Область	Предусмотренные действия
Поиск	Аккаунт по UUID, точному нормализованному email или отображаемому имени; фильтры типа, состояния и дат; компания по UUID или названию
Карточка аккаунта	Тип, состояние, подтверждение, ограничения и их происхождение, сводка сессий, ход удаления, связанные решения, профиль либо членства
Карточка компании	Жизненный цикл, состояние модерации, владелец, участники, приглашения, сводка вакансий
Ограничения аккаунта	Блокировка, отзыв сессий, запрет отдельных возможностей, например публикации или поиска
Удаление и восстановление	Обратимое мягкое удаление с обязательной конечной политикой хранения и последующим восстановлением; необратимое стирание — отдельное действие с отдельным правом
Компания	Управление участниками и приглашениями, передача владения, блокировка, архивирование, ограничения публикаций
Контроль	История действий, причины, состояния исполнения и восстановление после ошибок

Чтение собирает Admin Gateway из разрешённых операторских RPC владельцев. Изменения проходят подготовку, решение и исполнение Backoffice. Сырой email и приватное отображаемое имя требуют ACCOUNT_PII_READ; пароли, секреты приглашений, приватные чаты и контактные раскрытия кандидатов этим модулем не выдаются.

Санкции по жалобе снимаются через процесс пересмотра ReviewCase/REVERSAL, а не произвольной прямой операцией. При удалении учитываются конечные сроки хранения, восстановление, удержания и координация владения компанией. Значения сроков обзор не назначает. Выдача себя за пользователя, массовые санкции и массовый экспорт в объём не входят.

Что зафиксировано на стенде

В журнале зафиксирована публикация контура на внутреннем стенде: gateway-admin, Admin UI, манифесты infra/k3s/geek-admin/, отдельный сертификат и ingress, DNS, тестовые операторы с правами и мониторинг. Записаны проверки входа, несовместимости audience между хостами, 404 старых операторских маршрутов на публичном хосте и сохранения публичных сценариев.

Карта разделов выше соответствует маршрутам и экранам apps/admin в исходниках frontend; полномочия и действия описаны контрактами backend. Проверка конкретного выпуска EXT-07 включает политики хранения и удаления, работу с данными и приёмку расширенных операций. Публичный адрес демонстрации не означает, что административный контур обязан оставаться открытым в корпоративной поставке.

Репозитории и структура кода · Все разделы · Эмулятор реестра ФСП