feat(web): mint scoped agent-binary install token, gate download endpoint (VS-60) #79
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/VS-60-agent-install-token-endpoint"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add GET /agentbinaries/install-token: a session-gated endpoint that mints a scoped, short-lived (5 min) agent-binary install token and returns it as JSON {"token": ""} so the vervain-apps enrollment dialog's mint_install_token deserializer consumes it unchanged. Returns 401 (no body) when the operator vervain_session cookie is absent or invalid. The enrollment flow was 404ing because this route did not exist (parent VS-54; the frontend dependency VAPP-35 shipped ahead of it).
Add the client-facing authorization VS-57 left unbuilt: agent_binary_download_handler (VS-56, /api/v1/agent/binary/:id) now authorizes BEFORE any upstream read, accepting EITHER a valid operator vervain_session (the admin browser button) OR a valid ?token= install token (the unattended device curl, which presents no cookie). Unauthorized requests get 401 with no binary bytes and no upstream detail.
The new InstallTokenStore mirrors control_token's in-memory, auto-GC design but is multi-use within its TTL (validate, not consume), since the same token is carried by both the operator-facing download button and the device-side curl. Scope and TTL are documented in the handler and store doc-comments.
Tests cover: mint with valid session (200 + non-empty token), mint without session (401), download with valid token (passes the auth gate), download with invalid/absent token (401), download with a session (still accepted), plus store mint/validate/expiry/multi-use units.
#VS-60
Add GET /agentbinaries/install-token: a session-gated endpoint that mints a scoped, short-lived (5 min) agent-binary install token and returns it as JSON {"token": "<value>"} so the vervain-apps enrollment dialog's mint_install_token deserializer consumes it unchanged. Returns 401 (no body) when the operator vervain_session cookie is absent or invalid. The enrollment flow was 404ing because this route did not exist (parent VS-54; the frontend dependency VAPP-35 shipped ahead of it). Add the client-facing authorization VS-57 left unbuilt: agent_binary_download_handler (VS-56, /api/v1/agent/binary/:id) now authorizes BEFORE any upstream read, accepting EITHER a valid operator vervain_session (the admin browser button) OR a valid ?token= install token (the unattended device curl, which presents no cookie). Unauthorized requests get 401 with no binary bytes and no upstream detail. The new InstallTokenStore mirrors control_token's in-memory, auto-GC design but is multi-use within its TTL (validate, not consume), since the same token is carried by both the operator-facing download button and the device-side curl. Scope and TTL are documented in the handler and store doc-comments. Tests cover: mint with valid session (200 + non-empty token), mint without session (401), download with valid token (passes the auth gate), download with invalid/absent token (401), download with a session (still accepted), plus store mint/validate/expiry/multi-use units. #VS-60