coulomb/railiance-apps
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
railiance-apps/docs/evidence/2026-09-12-account-recovery-live.md
tegwick 1e52ab9497 Record deployed account recovery and current pilot image 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c
2026-09-12 10:50:35 +02:00

3.5 KiB
Raw Blame History

Account recovery live verification — 2026-09-12

The operator requested recovery after a rejected product login, visible identity and tenant/workload access, and logout/account switching.

Deployed revisions

  • KeyCape source 4d8b8fe934ebd4dbde030b7f76f1528eb6c657fa, Forgejo image run 48.
  • User Engine source e54b6ee9705b8b7ceff877985abc3aa0231dddfc, smoke 127 and image 128.
  • Vergabe source c067993037f1cdeeb7b22d5600b51c649bc239db, acceptance 58, smoke 59, image 60.

All listed CI jobs succeeded. Immutable runtime images:

  • key-cape: forgejo.coulomb.social/coulomb/key-cape@sha256:5f58563aa903ffa0c060e5ae9eb436aa963322d26bdde393efd2dd506dc6c4ed
  • user-engine: forgejo.coulomb.social/coulomb/user-engine@sha256:8621032bacc3da5a4c8c96775422263d4b0cf775744126aa50c002b0a678ec5b
  • vergabe-teilnahme: forgejo.coulomb.social/coulomb/vergabe-teilnahme@sha256:a26444f59c259698159c69ccb96f73dc648a261ece4c86bb2037a9d977870d91

Verification and operational effects

All three Deployments are 1/1 Ready. Provider updates used UID/resourceVersion and old-image guards plus server dry-run. Vergabe is Helm revision 3; the canonical values render exactly the installed manifest. Requests remain KeyCape 25m/32Mi, User Engine 50m/64Mi, Vergabe 60m/256Mi. User Engine changed to Recreate because there was insufficient CPU for a surge replica. Its initial startup encountered a transient database connection refusal and recovered after one restart. The rollout clears process-local portal/issuer sessions; no data or credentials changed.

126 Vergabe tests passed on isolated SQLite, 182 portal tests passed (three optional integration skips), layer conformance passed, Go suite and final targeted OIDC/config checks passed, and four runtime packaging tests passed.

Six live provider checks preserve fresh-login forwarding, exact callbacks and PKCE refusal for both clients. Eleven live product checks preserve CSRF, private data/media protection and correct OIDC start; invalid callback/confirmation now redirect to the fixed recovery URL. Product ingress uses same-origin referrer policy, so cross-origin recovery receives no callback referrer; issuer errors use no-referrer directly.

Six checks in a fresh isolated Chromium browser passed against the final live images without header overrides: public recovery page, visible logout control, expired callback stripped to recovery, explicit shared sign-out confirmation, POST through Authelia returning to /logged-out, and visible sign-in afterward. No user credentials, personal browser profile, MFA token or authenticated user session was used. Actual authenticated identity switching remains unverified.

Browser verification caught and corrected two issues before final acceptance: no-referrer suppressed the POST Origin, and form-action self blocked the provider redirect. The confirmation now preserves same-origin Origin and permits only the owner-configured provider and portal origins in that directive. A test-only header override validated the correction, followed by the six final checks without it.

Remaining live work

KEY-WP-0034-T02 and USER-WP-0026-T02 await real-user account-switch acceptance. USER-WP-0026-T03 owns a complete authoritative workload catalogue. The current account page shows verified portal identity, tenant and roles, memberships and recorded workload memberships; it does not infer access from absent records or claim a complete fleet allow list. Existing application sessions and issued JWTs may remain valid after shared provider logout.