fix(crossview): OIDC redirect_uri is built from the request, not OIDC_CALLBACK_URL

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

Login to Crossview fails at Dex with Unregistered redirect_uri ("http://crossview.platform.devantler.tech/api/auth/oidc/callback").

#3171 fixes the proven half — the app never rolls when its ConfigMap changes, so it was running a
stale OIDC_CALLBACK_URL. This issue tracks a second, independent problem that a restart may not
resolve, and it is the one that decides whether login actually works.

The redirect_uri Dex received matches neither the config the pod is running nor the config in
Git:

Source	Value
Pod's env at the time (from the pre-#2741 ConfigMap)	http://localhost:3001/api/auth/oidc/callback
Git / current ConfigMap	https://crossview.platform.devantler.tech/api/auth/oidc/callback
What Dex actually received	http://crossview.platform.devantler.tech/api/auth/oidc/callback

The host is the public route, the scheme is http, and the path is the app's fixed
callback route. That combination is only explicable if Crossview builds the authorization request's
redirect_uri from the incoming request (Host header + connection scheme) rather than using
OIDC_CALLBACK_URL verbatim. The hop into the pod is plaintext (Gateway → oauth2-proxy → auth-proxy →
Crossview), so the scheme it observes is http.

Supporting facts, all measured read-only in prod:

• OIDC_CALLBACK_URL reaches the container only via env[].valueFrom.configMapKeyRef.
• The active ReplicaSet crossview-55d64b565 dates from 2026-07-05; the pod template has not
  changed since, and the container has restarts=0 since 16:26:36Z.
• crossview-config was last written by helm-controller at 16:48:08Z — after the container started.

Why it matters

If Crossview derives the origin, then #3171 plus a restart is not sufficient: the app will still
send http://… and Dex will still reject it, because Dex matches redirect URIs exactly.

Expected behaviour

Crossview sends https://crossview.platform.devantler.tech/api/auth/oidc/callback — the value already
registered on the shared Dex client.

Candidate fixes, in preference order

1. Make Crossview honour the forwarded scheme. Confirm whether it reads X-Forwarded-Proto, and
   ensure that header reaches it as https. The route already sets X-Auth-Request-Redirect for
   oauth2-proxy, but nothing sets X-Forwarded-Proto for Crossview itself.
2. Make it use OIDC_CALLBACK_URL verbatim — an upstream fix or a chart/config option, if one
   exists for the authorize step.
3. ❌ Do not register the http:// variant on the Dex client. That makes Dex accept a plaintext
   redirect target for a public route and trades the vulnerability for the symptom.

Acceptance criteria

• A login through the public route completes end to end.
• Dex receives an https:// redirect_uri (confirmable from a Dex log line or a failed-request body).
• The Dex client still registers only the HTTPS callback.
• A negative control: reverting the fix reproduces the http:// redirect_uri, so the fix is shown to
  be what changed the behaviour.

Blocked by

#3171 — land the reload fix first, restart, and re-observe. If login then works, Crossview does use
the configured value and this issue closes as not-reproducible with that recorded.

[devantler]

🤖 Generated by the Agentic Engineer

Confirmed. The maintainer restarted the deployment and login still fails with the same http://
redirect_uri, which settles the open question in this issue.

The restart demonstrably took effect:

New pod	crossview-667fcb657-qk6gv, started 2026-08-16T19:12:08Z
New ReplicaSet	crossview-667fcb657, created at the same instant
OIDC_CALLBACK_URL it resolved	https://crossview.platform.devantler.tech/api/auth/oidc/callback

So the pod was holding the correct HTTPS value and still emitted http://. Crossview does not
use OIDC_CALLBACK_URL for the authorization request's redirect_uri; it builds it from the
incoming request. Host comes from the Host header, path is the app's fixed callback route, and the
scheme is whatever it believes the request used.

This also retro-explains the very first observation, which had looked contradictory: at that point
the pod's env still held http://localhost:3001/..., yet Dex received the public host. Under
"derives from the request" both readings are consistent — the host was never coming from config.

Cause of the http: every hop in front of the app is plaintext — the Gateway terminates TLS,
then oauth2-proxy, then auth-proxy's :8080 entryPoint — and Traefik derives X-Forwarded-Proto
from its own entryPoint scheme, overwriting whatever arrived. So the app is told every request came
over plain HTTP.

Ruled out as a fix: the chart exposes no base-URL, public-URL, or trust-proxy setting. Its full
env surface is AUTH_*, CORS_ORIGIN, DB_*, LOG_LEVEL, OIDC_*, PORT, SAML_* — nothing
that names the public origin except OIDC_CALLBACK_URL, which we have now proven is not used for
this. (The chart's proxy: key is Vite dev-server config, unrelated.)

Fix proposed in #3177: assert the real client scheme on the crossview route only.