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

Merged

forgejo-admin merged 3 commits from feature/5_api_health_and_cors into main

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

developer commented

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

Collaborator

Что сделано

Серверная часть плана UI-хаба агентов (#1, этап A из обсуждения в #1):

GET /api/health — healthcheck с той же Bearer-авторизацией, что и остальное /api:
- 200 + { status: "ok"|"degraded", sessionsDir, sessionsDirExists, uptimeMs } при верном токене;
- 401 без токена / с неверным.
  Позволяет UI-хабу (этап B, #6) различать «машина/порт недоступны», «неверный токен» и «OK».
ALLOWED_ORIGINS — новая опциональная переменная окружения: список origin через запятую. Для запросов к /api/* с разрешённым Origin отдаются CORS-заголовки (Access-Control-Allow-Origin с эхом origin + Vary: Origin, методы GET, OPTIONS, заголовки Authorization, Content-Type), preflight OPTIONS отвечает 204. Переменная не задана — поведение прежнее (same-origin, без CORS-заголовков). Preflight отвечает всегда, но без заголовков для неразрешённых origin — браузер такой запрос отклоняет.
Документация: ALLOWED_ORIGINS в таблице конфигурации README, GET /api/health в разделе API, пример curl-проверки в разделе systemd, закомментированная переменная в deploy/pi-web-monitor.service.

Обратно совместимо: без ALLOWED_ORIGINS поведение сервера не меняется.

Как проверить

npm test — 33 теста (5 новых: healthcheck ×2, CORS ×3), все зелёные.
Ручная проверка: curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:8787/api/health → JSON со status: ok.
ALLOWED_ORIGINS=http://example.com + запрос с Origin: http://example.com → заголовок Access-Control-Allow-Origin: http://example.com; с другим origin — заголовка нет.

Closes #5

## Что сделано Серверная часть плана UI-хаба агентов (#1, этап A из обсуждения в #1): 1. **`GET /api/health`** — healthcheck с той же Bearer-авторизацией, что и остальное `/api`: - `200` + `{ status: "ok"|"degraded", sessionsDir, sessionsDirExists, uptimeMs }` при верном токене; - `401` без токена / с неверным. Позволяет UI-хабу (этап B, #6) различать «машина/порт недоступны», «неверный токен» и «OK». 2. **`ALLOWED_ORIGINS`** — новая опциональная переменная окружения: список origin через запятую. Для запросов к `/api/*` с разрешённым `Origin` отдаются CORS-заголовки (`Access-Control-Allow-Origin` с эхом origin + `Vary: Origin`, методы `GET, OPTIONS`, заголовки `Authorization, Content-Type`), preflight `OPTIONS` отвечает `204`. Переменная не задана — поведение прежнее (same-origin, без CORS-заголовков). Preflight отвечает всегда, но без заголовков для неразрешённых origin — браузер такой запрос отклоняет. 3. Документация: `ALLOWED_ORIGINS` в таблице конфигурации README, `GET /api/health` в разделе API, пример curl-проверки в разделе systemd, закомментированная переменная в `deploy/pi-web-monitor.service`. Обратно совместимо: без `ALLOWED_ORIGINS` поведение сервера не меняется. ## Как проверить 1. `npm test` — 33 теста (5 новых: healthcheck ×2, CORS ×3), все зелёные. 2. Ручная проверка: `curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:8787/api/health` → JSON со `status: ok`. 3. `ALLOWED_ORIGINS=http://example.com` + запрос с `Origin: http://example.com` → заголовок `Access-Control-Allow-Origin: http://example.com`; с другим origin — заголовка нет. Closes #5

developer added 2 commits

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

feat(config): parse ALLOWED_ORIGINS into allowedOrigins list e4c7728c5f

feat(api): add GET /api/health endpoint and opt-in CORS for API 82e36e9037

developer referenced this pull request

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

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

forgejo-admin added 1 commit

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