Stage the KeyCape public-origin headers on Authelia 4.38.
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 2s

Assistant: grok
Assistant-Session: 01a0e27d-3c2d-7571-a4f8-95442f282b6f
This commit is contained in:
tegwick 2026-09-27 13:52:45 +02:00
parent 928268a479
commit 5385880d19
2 changed files with 13 additions and 2 deletions

View file

@ -215,3 +215,12 @@ allowed back-channel. key-cape is asked whether it will send
that existing call (path B). Authelia 4.39 trusting those headers from a
pod, rather than from Traefik, is still unverified. No live config or image
was changed.
2026-09-27, path B shipped by key-cape and staged on Authelia 4.38.
`ADMINISTER @ realm:kubernetes/railiance01`, `activation=APPROVED` for this
image change only. Commit `3b0446e`, tag `main-3b0446e`, digest
`sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3`.
The token call stays in-cluster and now sets those two headers from
`browserBaseURL`. Authelia remains `sha256:46021dc2…` (4.38). Rollback
digest `sha256:82f1e5ac…`. The 4.39.28 upgrade waits for one attended
sign-in through the Vergabe demo-company welcome on this image.