feat: add --auth-key CLI flag and wire auth into HTTP server#48
feat: add --auth-key CLI flag and wire auth into HTTP server#48
Conversation
The AuthStore existed but was never integrated into the server or exposed via CLI. This meant auth was effectively dead code. Changes: - Add --auth-key <key> CLI flag that registers an admin API key - Wire AuthStore into Database struct so it's accessible from server - HTTP server now enforces auth on all data endpoints when enabled - /health and /metrics remain public (no key needed) - All /db/*, /collections, /branch/*, /cdc/* require X-Api-Key - Add 401 Unauthorized HTTP status to error handler - Unknown CLI flags now error immediately instead of being silently ignored No auth configured → open access (dev mode), same as before. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7b5ce90476
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| _ = db.auth.addKey(key, "cli", .admin); | ||
| std.log.info("Auth enabled (--auth-key)", .{}); |
There was a problem hiding this comment.
Enforce --auth-key on wire protocol requests
Adding the CLI key here enables auth state globally, but only the HTTP path checks it; WireServer still executes INSERT/GET/UPDATE/DELETE/SCAN without any auth handshake or key verification. In the default --wire mode (or --both for wire clients), users can still read/write data anonymously even after starting with --auth-key, which violates the flag contract and leaves production deployments unintentionally exposed.
Useful? React with 👍 / 👎.
| const api_key = auth.AuthStore.extractHttpKey(raw) orelse | ||
| return err(401, "unauthorized — missing X-Api-Key header"); |
There was a problem hiding this comment.
Parse X-Api-Key header case-insensitively
This auth gate depends on extractHttpKey, which matches only the exact literal X-Api-Key: ; HTTP header names are case-insensitive, and many clients/proxies normalize to lowercase (x-api-key). With auth enabled, correctly authenticated requests from those environments will be rejected as missing credentials, causing avoidable 401s for valid traffic.
Useful? React with 👍 / 👎.
Summary
--auth-key <key>CLI flag that registers an admin API key via the existingAuthStoreAuthStoreintoDatabasestruct and enforce auth in the HTTP server'sdispatchfunction/healthand/metricsremain public; all data endpoints (/db/*,/collections,/branch/*,/cdc/*) requireX-Api-Keyheader when auth is enabled401 Unauthorizedto the HTTP error handlerNo auth configured → open access (dev mode), same as before. Zero breaking changes.
Test plan
--auth-key test→ health works without key, data endpoints require key--auth-keyflag → open access (backwards compatible)--bogus→ immediate error with message🤖 Generated with Claude Code