feat(api): add API keys and the integration API #8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/api-keys"
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?
Summary
/api/v1) for nodes, resources, targets and headers, described by a public OpenAPI 3.1 document.feat/backend-tls); retarget tomainonce #2 to #7 are merged.Changes
api_keystable (reversible, portable): name, read or write access, optional expiry, last use, creator (kept as null if the user is deleted). Keys are random 256-bit secrets (tck_...) stored only as SHA-256 and shown once, like node tokens.ApiKeyscontext and a key-backedScope(no user; write acts as admin, read as member), so the existing context authorization applies unchanged. Keys can never create, list or revoke keys, so a leaked key cannot mint a successor.ApiKeyAuth(one uniform 401 for every failure; no session or cookie is ever consulted),ApiWriteAccess(read keys get 403 on anything but GET/HEAD/OPTIONS before a controller runs, as a second line of defense),ApiPathIds(malformed ids are 404).{"data": ...}; every error is{"errors": ...}. Other organizations' records are 404. Controllers answer 404 themselves so the shape does not depend on the environment (in development Phoenix would otherwise render a debug page with the failing query).Api.Specis the OpenAPI document as code, served publicly at/api/v1/openapi.json.Verification
compile --warnings-as-errors,credo --strictclean;mix dialyzer0 errors on both backends./api/v1route refuses missing, malformed, wrong-kind, expired and revoked keys with the same 401, and every write route refuses read keys with 403, including routes added later. Tenant isolation, mass assignment, a secrets sweep of every response, and a contract test tying the OpenAPI document to the router, the serializer, the Ecto enums and every documented input.Not included
- organization admins create read or write API keys with an optional expiry; keys are random 256-bit secrets stored only as SHA-256 and shown once, and revoking one takes effect immediately - a key authenticates /api/v1 requests with a bearer header and runs with the organization's scope (write acts as admin, read as member), so the existing context authorization applies; keys can never create, list or revoke keys - /api/v1 covers the organization, nodes, resources, targets and headers; every error is {"errors": ...}, other organizations' records are 404, and secrets are never serialized - the OpenAPI 3.1 description is code, served publicly, and held to the router, the serializer and the accepted inputs by tests - an API keys page for admins, linked from the organization page