Server-side Supabase calls (middleware getUser/refresh, server components,
admin client) all egress through the Docker gateway as a single NATed IP and
traverse Caddy's per-IP /auth/* rate limiter (8 events/s). A handful of active
users saturate that shared bucket, 429ing getUser()/token refresh; the
middleware then treats the session as invalid and bounces to /login, while a
manual refresh lands under budget and works again.
Add SUPABASE_INTERNAL_URL (e.g. http://kong-prod:8000) used only by the
server-side clients (middleware, lib/supabase/server.ts, admin getSupabaseAdmin
/getSupabaseAnon), falling back to the public URL when unset. Browser clients
keep the public URL so real per-user-IP edge rate limiting still applies.
Also bake the arg in the Dockerfile/build and make the web-prod network alias
durable via WEB_ALIAS (dev sets web-dev) so the dev container can't reclaim the
web-prod alias on redeploy.
When getUser() rejects a present session cookie with user_not_found /
session_not_found / bad_jwt (e.g. a deleted account or a cookie that
outlived its session), the middleware now clears the sb-*-auth-token
cookies and redirects to /login instead of leaving the browser wedged
in a logged-out page that still renders a Sign out button.
The defense-in-depth admin guard in middleware short-circuits before the
route handlers' jsonNoStore runs, so its 401/403 JSON denials (and auth
redirects) were served without Cache-Control: no-store. Stamp no-store in
withCookies so every admin deny/redirect response is non-cacheable,
completing Finding #4 for the middleware-originated admin responses.
Gerhard Scheikl