Coffee Server: Module 3

Module 3

Keyman — who’s at the door

Keyman is the Guardian vertical: authentication and policy on the main server process. The tagline fits: who’s at the door before Vault RPCs or file routes run. Until you bootstrap Keyman, sensitive routes may be wide open — fine on a trusted machine while you learn, dangerous if you expose the server to the public internet.

Bootstrap → session → Bearer

Typical flow: POST /api/keyman/bootstrap creates initial admin state under ROOT_DIR/.coffee/keyman/, then login returns a session token. Clients send Authorization: Bearer <token> on API calls. API keys (ck_…) suit scripts and integrations.

COFFEE_KEYMAN_DISABLE=true turns enforcement off — use only when you understand the tradeoff.

Policy

Policy can tighten which routes require auth. The POC HTML pages (KEYMAN1 mock, KEYMAN2 login) are there to visualize toggles and flows; production discipline is: enforce on the server, never only hide buttons in the browser.

Read KEYMAN-ARC.md for tunnels: a public URL to your crib without Keyman on file/vault routes is an open disk invitation to the world.

Controlled version of “real” auth

Cloud platforms give IAM, OAuth apps, and service accounts. Keyman is the same shape — principals, secrets, middleware on routes — without AWS’s entire console. You learn the invariants: least privilege, revocable keys, secrets never pasted into shared docs or screenshots.

Browser + Vault together

In practice the browser keeps a session, attaches a Bearer token to fetch for vault routes, and raw file previews depend on that same handshake. If a preview returns 401, suspect reachability + token, not “Vault is broken.”

Keyman login POC KEYMAN1 policy mock