Stage the KeyCape public-origin headers on Authelia 4.38.
Assistant: grok Assistant-Session: 01a0e27d-3c2d-7571-a4f8-95442f282b6f
This commit is contained in:
parent
928268a479
commit
5385880d19
2 changed files with 13 additions and 2 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue