Release v0.2.0: multiple named API keys per user
Replaces the single per-user DRF token with named, individually-revocable
API keys, so you can run one key per agent and cut off a leaked one without
disrupting the others.
- New ApiKey model (user, name, dbk_-prefixed key, created_at, last_used_at).
Data migration copies every existing authtoken 1:1 into a "default" named
key with the same value, so no client (incl. the sibling test project's
hardcoded test-user key) needs reconfiguring.
- Auth (resolve_token_user) resolves against ApiKey and stamps last_used_at,
throttled to one write/minute.
- Settings -> API Keys: table with name/key/created/last-used + per-row
revoke and a create form; keys viewable on demand. Settings -> Account now
links here; Settings -> Users issues a named initial key.
- Gated provisioning API for test installations: GET/POST /api/keys and
DELETE /api/keys/{id}, controlled by DAYBOOK_KEY_PROVISIONING_API (unset ->
follows DEBUG, so off in deployment). Advertised via key_provisioning_api
in /api/capabilities; 403 when disabled.
- Docs (api/deployment/quickstart/posting-helper), SKILL.md, and env.example
updated from "token / Settings -> Account" to "key / Settings -> API Keys".
- Tests: new API + UI suites for keys; existing token-based tests moved to
ApiKey. Full suite 129 passing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
5c46f2aa67
commit
19c1798f90
24 changed files with 602 additions and 63 deletions
39
docs/api.md
39
docs/api.md
|
|
@ -8,13 +8,13 @@ Base URL while running locally:
|
|||
http://127.0.0.1:8001
|
||||
```
|
||||
|
||||
Authentication for write endpoints (POST/PATCH) — a personal per-user API token, from Settings → Account in the app:
|
||||
Authentication for write endpoints (POST/PATCH/DELETE) — a personal API key, created in the app under Settings → API Keys. Each user can hold several (one per agent/script) and revoke them individually:
|
||||
|
||||
```http
|
||||
Authorization: Bearer <your-personal-token>
|
||||
Authorization: Bearer <your-personal-key>
|
||||
```
|
||||
|
||||
Every artifact belongs to the user whose token authenticated the POST — feeds are private per user.
|
||||
Every artifact belongs to the user whose key authenticated the POST — feeds are private per user.
|
||||
|
||||
Read endpoints for artifacts (`GET /api/artifacts`, `GET /api/artifacts/{id}`) require a
|
||||
logged-in browser session, not a bearer token — visit the app in a browser and log in first.
|
||||
|
|
@ -575,9 +575,40 @@ curl -H "Authorization: Bearer <your-personal-token>" http://127.0.0.1:8001/api/
|
|||
|
||||
Discover it programmatically via `skill_url` in the capabilities response.
|
||||
|
||||
## API Keys (provisioning)
|
||||
|
||||
Keys are normally created and revoked in the app under **Settings → API Keys**.
|
||||
For automated test installations, a programmatic surface can provision them
|
||||
too — but it is **gated** and **off in deployment**, because it returns key
|
||||
material over the API.
|
||||
|
||||
The gate is `DAYBOOK_KEY_PROVISIONING_API`. Unset, it follows `DJANGO_DEBUG`
|
||||
(on locally, off in production); set it explicitly (`0`/`1`) to override.
|
||||
`GET /api/capabilities` reports the current state as `key_provisioning_api`,
|
||||
and only lists the `/api/keys` methods when it's enabled. When disabled, every
|
||||
method below returns `403`.
|
||||
|
||||
```http
|
||||
GET /api/keys # list this user's keys (incl. key values)
|
||||
POST /api/keys # body {"name": "hermes-agent"} -> the new key
|
||||
DELETE /api/keys/{id} # revoke one key
|
||||
```
|
||||
|
||||
Authenticated by a browser session **or** an existing bearer key, and only
|
||||
ever operates on the authenticated user's own keys.
|
||||
|
||||
```bash
|
||||
# Create a new named key (test installations only)
|
||||
curl -X POST -H "Authorization: Bearer <existing-key>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"name": "hermes-agent"}' \
|
||||
http://127.0.0.1:8001/api/keys
|
||||
```
|
||||
|
||||
## Current MVP Constraints
|
||||
|
||||
- Each user has a personal ingest API token; there is no shared token.
|
||||
- Each user can hold several personal API keys (Settings → API Keys), each
|
||||
individually revocable; there is no shared key.
|
||||
- Reader/browser access requires login; feeds are private per user (except
|
||||
per-artifact public share links — see Sharing above).
|
||||
- Content modification/revisions are deferred (`PATCH` edits metadata only,
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue