KBVE Gate

KBVE Gate

kbve-gate is a thin authentication reverse-proxy built on the kbve crate’s feature-gated gate module. It runs as a sidecar in front of an internal service so the upstream binds localhost and only the gate is exposed.

Auth

The gate accepts a Supabase JWT from an Authorization: Bearer header, an sb-access-token / kbve_gate cookie, or an ?access_token= query param. After the JWT validates it applies an authz policy:

• jwt-only — any valid Supabase JWT passes.
• is_staff — forum.is_staff(sub) must return true. The gate mints a short-lived service_role JWT from SUPABASE_JWT_SECRET to call PostgREST, so the stale stored service-key is never used.

Configuration

Env	Default	Purpose
GATE_LISTEN	0.0.0.0:5678	bind address
GATE_UPSTREAM	http://127.0.0.1:5679	upstream base URL
GATE_AUTHZ	is_staff	is_staff or jwt-only
GATE_UPSTREAM_BASIC	—	Basic <b64> injected downstream
GATE_LOGIN_REDIRECT	—	302 target for unauthed browser navigations
GATE_COOKIE_DOMAIN	—	domain scope for the minted session cookie (e.g. .kbve.com)
SUPABASE_JWT_SECRET	—	required
SUPABASE_URL	—	required for is_staff (direct PostgREST)

Login bounce

The KBVE session lives in the browser (IndexedDB), so a cross-subdomain navigation carries no token. The gate completes auth with a bounce:

1. Unauthed navigation to a gated host → 302 to GATE_LOGIN_REDIRECT?redirect_to=<original URL>.
2. The login page, once a session exists, returns the browser to redirect_to?access_token=<jwt>.
3. The gate validates the token, sets a kbve_gate cookie scoped to GATE_COOKIE_DOMAIN, and 302s to a clean URL. Subsequent requests carry the cookie.

The login page only honours redirect_to targets on *.kbve.com over https, so the token can never be handed to a foreign origin.

n8n deployment

The first consumer fronts n8n: n8n moves to 127.0.0.1:5681, the gate owns the Service port 5678, and n8n.kbve.com routes through it so the panel stays staff-only.