fix: make a failed login on a deployed instance diagnosable - #274
Merged
Conversation
Auth.js error objects carry only a documentation link in `message`; the
reason lives on `cause`, wrapped once more as `cause.err`. Both are
non-enumerable, so logging `{ error }` recorded the link alone — in a
deployed instance a spent state cookie could not be told apart from a
refused token exchange without reading Keycloak's own event log to rule
the exchange out.
Fields are whitelisted rather than spread: `cause` is shaped by
@auth/core and oauth4webapi, and neither promises to keep request
parameters or token material out of it.
Two values that a first production deployment gets wrong quietly. `keycloak.admin` claimed its password comes from the realm JSON. It does not: that account lives in the `master` realm and a realm export carries only the exported realm's users. The chart declares no password for it at all, so whoever deploys has to set the subchart's own. The comment now says so, and flags that `hackagon-admin` names two different accounts — the console admin here, and the platform admin inside the realm. `server.adminkeycloakid` had no comment. Casbin grants the `admin` role to exactly this Keycloak user id and the backend seeds the admin row by it, so an admin created by hand in the console — fresh uuid — leaves nobody an admin, with nothing logged to explain it. Comments only; no rendered output changes.
sabinem
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A login on the deployed app ended at /auth/error?error=Configuration with no way to find out why. That page is Auth.js's catch-all — a stale tab, a re-submitted callback and a rejected token exchange all look identical — and the pod log recorded only "Read more at …#callbackrouteerror". Working out the real cause meant pulling Keycloak's event log and proving the token exchange had never been attempted. It was a callback submitted twice, reusing an already-spent authorization code.
The log threw the answer away: Auth.js puts a doc link in message and the reason on cause (wrapped again as cause.err), both non-enumerable, so { error } saved only the link. It now logs the error class and the cause, so the next one explains itself.
Also documents two Helm values that fail silently on a first production deploy: keycloak.admin (its password is not in the realm JSON — different realm, and the chart sets none) and server.adminkeycloakid (casbin grants admin to exactly that UUID, so an admin created by hand in the console leaves nobody an admin).
Left out