Ilker ManapandClaude Opus 5
3ed211b2f4
CI / test (push) Successful in 2m43s
Issuing a key worked; getting it to the person it was issued for did not. The operator had a secret on their terminal and no way to send it that did not leave a bearer credential in a chat log forever. `keys create --claim` prints a link instead. GET shows a button and consumes nothing; POST reveals the key and burns the link. That split is not politeness — chat clients, mail scanners and link previewers fetch URLs the moment they are posted, so a GET that consumed the claim would mean the first thing to unfurl the link destroys the key before anyone reads it. A pending claim has to hold the key somewhere, which would otherwise put a working credential in the database and undo what hashing bought. So the key is sealed with a key derived from the link's own token, and the token is never stored — only its hash. A database leak yields two useless hashes and a blob nothing in the database can open. HKDF rather than the raw token, so the value used for lookup can never become the value that decrypts. Consuming is one UPDATE moving claimed_at off NULL, so two people opening the same link produce one key rather than two copies. A used link, an expired one and a token that was never real all render identically, because saying which confirms that a token was once valid. The page is no-store, no-referrer and noindex: the URL is itself the credential. `GET /me` reports a key's own limits and spend, so nobody has to ask an operator to read a dashboard they cannot reach. Outside /v1, because it is not part of the OpenAI API. docs/onboarding.md is written for whoever operates this, including the parts that are deliberately absent — no self-service, no SSO, and why. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 lines
1015 B
SQL
21 lines
1015 B
SQL
-- A key has to reach the person it was issued for, and a key pasted into a chat
|
|
-- window stays in that chat window forever. A claim is a one-time link instead:
|
|
-- the operator sends the link, the person opens it once, and the link dies.
|
|
--
|
|
-- The key is not stored here in the clear. It is sealed with a key derived from
|
|
-- the claim token, and the token is never written down — only its hash is. So a
|
|
-- database leak yields two useless hashes and a blob nothing in the database can
|
|
-- open, which keeps the property the api_keys table has.
|
|
CREATE TABLE key_claims (
|
|
token_hash BLOB PRIMARY KEY,
|
|
key_id TEXT NOT NULL REFERENCES api_keys(id),
|
|
-- The sealed key. Emptied the moment it is claimed, so a claimed link leaves
|
|
-- nothing behind even before the row is purged.
|
|
sealed BLOB NOT NULL,
|
|
created_at INTEGER NOT NULL,
|
|
expires_at INTEGER NOT NULL,
|
|
claimed_at INTEGER
|
|
);
|
|
CREATE INDEX key_claims_by_key ON key_claims(key_id);
|
|
CREATE INDEX key_claims_by_expiry ON key_claims(expires_at);
|