Skip to content

Optional gate to restrict Apollo to known clients (idea)#537

Closed
elias-ba wants to merge 3 commits into
mainfrom
instance-auth-lockdown
Closed

Optional gate to restrict Apollo to known clients (idea)#537
elias-ba wants to merge 3 commits into
mainfrom
instance-auth-lockdown

Conversation

@elias-ba

@elias-ba elias-ba commented Jun 18, 2026

Copy link
Copy Markdown
Collaborator

Description

This branch holds an optional access gate for Apollo. When turned on, every request to /services/* must carry a valid client token, and anything without one is rejected. It's the stricter sibling of the per-client key mapping in #536: that one only recognises tokens, this one requires them.

It builds on the same lightning_clients table and token hashing, and adds:

  • token checking on every request, with a clear 401 when the token is missing or invalid;
  • a safe default: if the gate is switched on but the client table can't be reached, it rejects requests rather than silently letting everyone in;
  • a shared secret for Apollo's own internal calls between services, so they keep working and aren't mistaken for outside traffic.

Why it's parked

  • It isn't needed for what we're doing now, Per-client API key mapping #536 covers that.
  • It can't be used yet anyway: a client would have to be changed to send a token on its requests, and nothing sends one today. So it's a larger change that reaches beyond this repo and is worth discussing on its own.

Parked here so the work isn't lost. We can pick it back up if we ever want an Apollo that only known clients can call.

Related: #536.

@elias-ba elias-ba changed the title Instance auth: hard gate for a locked-down Apollo (parked) instance auth: hard gate for a locked-down Jun 18, 2026
…t trust

Builds on the concept PR with a tested, dependency-injected foundation:
- createInstanceAuth(config) with DI; no module globals or test seams. Typed
  AuthContext replaces ad-hoc any.
- resolveAuthConfigFromEnv() owns env/DB/Bun.SQL resolution and fails CLOSED
  (deny-all) when enabled but the table/runtime is unusable.
- createDbLookup(): TTL cache + single-flight refresh + serve-stale on error.
- Internal service-to-service auth via auto-generated APOLLO_INTERNAL_SECRET
  (inherited by spawned services); never network-address trust.
- External requests: strip caller-supplied api_key, inject the resolved key.
- Fix: handlers reference ctx.body directly so Elysia parses the body.
- Lazy Bun.SQL import (requires Bun >= 1.2); bump local .tool-versions only.
  Prod/CI already install a newer Bun, so the Dockerfile and CI are untouched.
- Tests: gate, cache, env fail-closed, and a pinned TS<->Python hash invariant.
  Full suite green (34 TS + 1 py).
- Changeset added.
@elias-ba elias-ba force-pushed the instance-auth-lockdown branch from 45a38a1 to 7a314e9 Compare June 18, 2026 04:08
@elias-ba elias-ba mentioned this pull request Jun 18, 2026
7 tasks
@elias-ba elias-ba changed the title instance auth: hard gate for a locked-down Optional gate to restrict Apollo to known clients (draft) Jun 18, 2026
@elias-ba elias-ba changed the title Optional gate to restrict Apollo to known clients (draft) Optional gate to restrict Apollo to known clients (idea) Jun 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants