diff --git a/workplans/NK-WP-0041-onboarding-journey-usability.md b/workplans/NK-WP-0041-onboarding-journey-usability.md index 90cfd2f..0a5a356 100644 --- a/workplans/NK-WP-0041-onboarding-journey-usability.md +++ b/workplans/NK-WP-0041-onboarding-journey-usability.md @@ -59,7 +59,7 @@ to a user; note it here if the password manager still misbehaves. ```task id: NK-WP-0041-T02 -status: progress +status: wait priority: medium state_hub_task_id: "83633649-3e5c-57e7-8207-609380a29c25" ``` @@ -145,3 +145,30 @@ The repository now pins the exact 4.38 digest instead of the floating tag. Separate finding: Authelia's LDAP startup check fails on the first start after a pod is scheduled, then passes on restart. + +Operator confirmation after the rollback, 2026-09-24: sign-in as +`bernd.worsch-99` works again. `bernd.worsch+99@gmail.com` still fails on +4.38, as expected. + +Root cause of the 4.39 break. KeyCape's `tokenBaseURL` is the in-cluster +`http://authelia.sso.svc.cluster.local:9091` (declared in +`sso-mfa/k8s/keycape/create-secrets.sh`). The token request sets no +forwarded headers (key-cape `adapter.go`), so Authelia sees an `http` +scheme. 4.38 accepts that; 4.39 will not derive an issuer from it. + +Path forward. Stage the fix on 4.38 first, then upgrade with only one +variable changing: + +- **A (preferred, config only).** Point `tokenBaseURL` at + `https://auth.coulomb.social`, so the call goes through the ingress with + `X-Forwarded-Proto: https`. First check that the KeyCape pod can reach the + public hostname in-cluster (hairpin). Apply through the guarded KeyCape + config lane with unrelated bytes preserved, then prove it with a real + login on 4.38. +- **B (code).** key-cape sends `X-Forwarded-Proto: https` and + `X-Forwarded-Host` on back-channel calls. Whether 4.39 trusts forwarded + headers from a pod is unverified. + +Then retry 4.39.28. The acceptance must include a real human sign-in +through KeyCape, and the `+` email sign-in. The task waits on the choice +of A or B, with key-cape consulted.