From ee8f9c8a67c1aa0a7f81dad240bd4a023c8f2d35 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 24 Sep 2026 01:57:20 +0200 Subject: [PATCH] NK-WP-0041-T02: rollback confirmed; 4.39 root cause and staged fix path Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 299762@bnt-lap001 Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e --- ...NK-WP-0041-onboarding-journey-usability.md | 29 ++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) 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.