Этап A: healthcheck-эндпоинт /api/health и CORS (ALLOWED_ORIGINS) #5

New issue

Closed

opened 2026-09-26 09:08:20 +00:00 by developer · 2 comments

developer commented

2026-09-26 09:08:20 +00:00

Collaborator

Подзадача этапа A из плана развития UI-хаба (#1).

Объём (только сервер, обратно совместимо)

GET /api/health — healthcheck с той же Bearer-авторизацией, что и остальное API:
- 200 — процесс жив, SESSIONS_DIR существует; тело — JSON со статусом сервиса;
- 401 — сервис есть, токен неверный.
Нужен UI-хабу (Этап B), чтобы различать состояния «машина/порт недоступны», «неверный токен» и «OK». Анонимный эндпоинт не делаем — он палит существование сервиса.
ALLOWED_ORIGINS — новая переменная конфига: список разрешённых origin через запятую. Если origin запроса есть в списке — отдаём CORS-заголовки и обрабатываем preflight OPTIONS; переменная не задана — поведение как сейчас (same-origin, без CORS-заголовков).
Тесты на оба пункта.

Критерии приёмки

/api/health без токена → 401, с верным токеном → 200 и JSON со статусом.
При ALLOWED_ORIGINS=http://example.com запрос с этим origin получает Access-Control-Allow-Origin, preflight OPTIONS отвечает корректно; без переменной — CORS-заголовков нет.
Все существующие тесты зелёные; текущий сценарий «UI с того же origin» не меняется.

Часть работ по #1. Следом — Этап B: реестр агентов и переключение в UI.

Подзадача этапа A из плана развития UI-хаба (#1). ## Объём (только сервер, обратно совместимо) 1. **`GET /api/health`** — healthcheck с той же Bearer-авторизацией, что и остальное API: - `200` — процесс жив, `SESSIONS_DIR` существует; тело — JSON со статусом сервиса; - `401` — сервис есть, токен неверный. Нужен UI-хабу (Этап B), чтобы различать состояния «машина/порт недоступны», «неверный токен» и «OK». Анонимный эндпоинт не делаем — он палит существование сервиса. 2. **`ALLOWED_ORIGINS`** — новая переменная конфига: список разрешённых origin через запятую. Если origin запроса есть в списке — отдаём CORS-заголовки и обрабатываем preflight `OPTIONS`; переменная не задана — поведение как сейчас (same-origin, без CORS-заголовков). 3. Тесты на оба пункта. ## Критерии приёмки - [ ] `/api/health` без токена → `401`, с верным токеном → `200` и JSON со статусом. - [ ] При `ALLOWED_ORIGINS=http://example.com` запрос с этим origin получает `Access-Control-Allow-Origin`, preflight `OPTIONS` отвечает корректно; без переменной — CORS-заголовков нет. - [ ] Все существующие тесты зелёные; текущий сценарий «UI с того же origin» не меняется. Часть работ по #1. Следом — Этап B: реестр агентов и переключение в UI.

developer self-assigned this

2026-09-26 09:08:20 +00:00

developer referenced this issue

2026-09-26 09:08:31 +00:00

Этап B: UI-хаб агентов — реестр подключений, модалка «Подключить агента» с healthcheck, переключение base URL #6

developer referenced this issue

2026-09-26 09:09:23 +00:00

Сервис на удаленной машине (вопрос) #1

developer added the

in_progress

label

2026-09-26 09:09:36 +00:00

developer commented

2026-09-26 09:09:49 +00:00

Author

Collaborator

Беру задачу, ветка feature/5_api_health_and_cors.

Беру задачу, ветка `feature/5_api_health_and_cors`.

developer referenced this issue from a pull request that will close it,

2026-09-26 09:18:05 +00:00

Add /api/health endpoint and opt-in CORS (ALLOWED_ORIGINS) #7

developer commented

2026-09-26 09:18:17 +00:00

Author

Collaborator

Готово, PR #7 на ревью, ветка feature/5_api_health_and_cors. Реализовано по TDD: 5 новых тестов (healthcheck ×2, CORS ×3), всего 33 — зелёные. Детали и как проверить — в описании PR.

Готово, PR #7 на ревью, ветка `feature/5_api_health_and_cors`. Реализовано по TDD: 5 новых тестов (healthcheck ×2, CORS ×3), всего 33 — зелёные. Детали и как проверить — в описании PR.

developer added

done

and removed

in_progress

labels

2026-09-26 09:18:23 +00:00