Record the Authelia 4.39.28 attempt and the MFA-check rollback.
Assistant: grok Assistant-Session: 01a0e27d-3c2d-7571-a4f8-95442f282b6f
This commit is contained in:
parent
5385880d19
commit
212b5893b5
1 changed files with 34 additions and 3 deletions
|
|
@ -221,6 +221,37 @@ was changed.
|
||||||
image change only. Commit `3b0446e`, tag `main-3b0446e`, digest
|
image change only. Commit `3b0446e`, tag `main-3b0446e`, digest
|
||||||
`sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3`.
|
`sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3`.
|
||||||
The token call stays in-cluster and now sets those two headers from
|
The token call stays in-cluster and now sets those two headers from
|
||||||
`browserBaseURL`. Authelia remains `sha256:46021dc2…` (4.38). Rollback
|
`browserBaseURL`. KeyCape rollback digest `sha256:82f1e5ac…`.
|
||||||
digest `sha256:82f1e5ac…`. The 4.39.28 upgrade waits for one attended
|
|
||||||
sign-in through the Vergabe demo-company welcome on this image.
|
2026-09-27, the founder reached the Vergabe confirmation page for
|
||||||
|
`bernd.worsch-99` ("Sie fahren mit bernd.worsch-99 fort") on this KeyCape
|
||||||
|
image with Authelia still 4.38. That is a completed demo-company sign-in,
|
||||||
|
so the header-bearing token call works against 4.38.
|
||||||
|
|
||||||
|
Authelia was then moved to 4.39.28, index digest `sha256:bd97cff4…`, under
|
||||||
|
the same `ADMINISTER @ realm:kubernetes/railiance01` approval, with rollback
|
||||||
|
required if the plus-address sign-in failed. The pre-upgrade database copy
|
||||||
|
is `backups/db.sqlite3.pre-4.39.28-20260927` (2,228,224 bytes). Startup
|
||||||
|
migrated storage schema 15 → 29, restarted once on the known LDAP race, and
|
||||||
|
then listened on 9091. Probes for `nk-probe@example.invalid` and
|
||||||
|
`nk-probe+x@example.invalid` both logged "user not found". The filter
|
||||||
|
compile error on `+` was gone.
|
||||||
|
|
||||||
|
The founder's following sign-in, using `bernd.worsch+99@gmail.com`, reached
|
||||||
|
KeyCape `/authorize/callback` and failed there. Telemetry at
|
||||||
|
2026-09-27T13:24:11Z is `error_type=mfa_check_error` for
|
||||||
|
`vergabe-demo-company`. The account site then failed the same way
|
||||||
|
(`user-engine-portal`, 13:25:02Z through 13:25:36Z) and showed
|
||||||
|
"Sign-in could not be completed". That error is raised only after Authelia's
|
||||||
|
callback has already returned a username, so the issuer rejection from the
|
||||||
|
2026-09-24 rollout did not recur. `decideAssurance` returned an error
|
||||||
|
(privacyIDEA token lookup or the policy store). The telemetry line does not
|
||||||
|
carry the underlying error.
|
||||||
|
|
||||||
|
Authelia was rolled back immediately. The 20260927 database copy was restored
|
||||||
|
over `db.sqlite3`, any sqlite wal/shm/journal beside it was removed, and the
|
||||||
|
image returned to `sha256:46021dc2…`. v4.38.19 started with the schema
|
||||||
|
already up to date and is listening. KeyCape stayed on `sha256:7c99cd6c…`.
|
||||||
|
T02 stays waiting: 4.39.28 identified the user, and the MFA check then
|
||||||
|
failed closed. Do not roll 4.39.28 forward again until that check is
|
||||||
|
explained. The plus-address filter defect remains on 4.38.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue