cpressland/rabbitdb
Watch
1
0
Fork
You've already forked rabbitdb
 0
Code Issues 4 Pull requests Projects Releases 32 Packages 2 Wiki Activity Actions

feat(api): scoped write access to the read-only REST API #25

New issue
Open
opened 2026-09-11 00:58:11 +01:00 by Hermes · 0 comments
Hermes commented 2026-09-11 00:58:11 +01:00
Collaborator
Copy link

Summary

The /api/v1 REST API is currently 100% read-only — all mutations require a session-cookie-authenticated HTMX request through the web UI. This blocks lightweight integrations (e.g. a phone shortcut, a Home Assistant automation, a physical NFC tag on a hutch) that want to do one specific, low-risk action like "mark this hutch cleaned" without a full login flow.

Proposal

  • Add a small number of scoped write endpoints under /api/v1, starting with the lowest-risk, highest-value ones:
    • POST /api/v1/hutches/{id}/mark-cleaned
    • POST /api/v1/hutches/{id}/mark-played
  • API keys currently only gate on "active", not role (see _get_api_user) — for write access we likely want to start enforcing role on the API layer too (e.g. require staff or above for write endpoints), rather than opening writes to any read-only key holder.
  • Consider a separate class of API key (read-only vs. read-write) so existing integrations relying on read-only access aren't unexpectedly granted write power.
  • Audit log entries for API-driven writes should record that the action came via API (e.g. a distinct user_id/source marker) for traceability.

Open questions

  • Which actions beyond hutch clean/playtime are worth exposing first? (rabbit status change? health record add, once that feature exists?)
  • New API key tier, or reuse existing keys with a role check?
## Summary The `/api/v1` REST API is currently 100% read-only — all mutations require a session-cookie-authenticated HTMX request through the web UI. This blocks lightweight integrations (e.g. a phone shortcut, a Home Assistant automation, a physical NFC tag on a hutch) that want to do one specific, low-risk action like "mark this hutch cleaned" without a full login flow. ## Proposal - Add a small number of scoped write endpoints under `/api/v1`, starting with the lowest-risk, highest-value ones: - `POST /api/v1/hutches/{id}/mark-cleaned` - `POST /api/v1/hutches/{id}/mark-played` - API keys currently only gate on "active", not role (see `_get_api_user`) — for write access we likely want to start enforcing role on the API layer too (e.g. require `staff` or above for write endpoints), rather than opening writes to any read-only key holder. - Consider a separate class of API key (read-only vs. read-write) so existing integrations relying on read-only access aren't unexpectedly granted write power. - Audit log entries for API-driven writes should record that the action came via API (e.g. a distinct `user_id`/source marker) for traceability. ## Open questions - Which actions beyond hutch clean/playtime are worth exposing first? (rabbit status change? health record add, once that feature exists?) - New API key tier, or reuse existing keys with a role check?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v1.9.2
v1.9.1
v1.9.0
v1.8.0
v1.7.0
v1.6.1
v1.6.0
v1.5.0
v1.4.0
v1.3.2
v1.3.1
v1.3.0
v1.2.0
v1.1.7
v1.1.6
v1.1.5
v1.1.4
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.10
v1.0.9
v1.0.8
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3
v1.0.2
v1.0.1
v1.0.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
cpressland/rabbitdb#25
No description provided.