Update Portal decisions for API security boundary

This commit is contained in:
jester 2026-04-30 19:28:40 +00:00
parent 9433acb787
commit efe4553c81

View File

@ -4,8 +4,10 @@
- Portal should consume API-normalized state, not talk directly to agents for normal status/actions.
- Portal should not keep fallback direct-agent bridges in the frontend repo once the API owns the supported route.
- Portal must never add or expose `INTERNAL_API_TOKEN` in browser/client code.
- Portal must treat admin/internal API routes as unavailable to normal browser UI; user-facing pages should call user-safe API routes only.
- Portal server deletion should use `DELETE /api/servers/{id}` with the logged-in user's JWT, not the legacy `DELETE /api/containers/{vmid}` path.
- Portal delete UX should map API responses explicitly, including `409` as `Stop host before deleting`.
- Portal compatibility must be revalidated after API control-plane hardening because JWT, ownership, admin, and internal-token boundaries can change response codes without changing UI code.
- `agentStatus === online` is not enough by itself for game action eligibility.
- `ready === false` does not automatically mean a stopped server is unstartable.
- Portal should not infer `Needs attention` from `connectable === false`; it must prefer specific API/host/operation states before falling back to error labels.
@ -28,3 +30,4 @@
## Tracking rule
- when Portal work completes, remove it from `OPEN_ITEMS.md`
- if it changes long-lived UX/state model assumptions, update `CURRENT_STATE.md` or this file
- after API hardening, verify Portal routes by behavior rather than assuming old `401`/`403`/`404` semantics are unchanged