2 Commits

Include renames

Author	SHA1	Message	Date
LeoVasanko	b9e6f4bc27	Separate related domains (ROR) from the in-domain sign-in allow-list ... RealmConfig.origins is again purely an allow-list of sign-in sites within the realm's domain (unset = rp-id and all subdomains), restoring the restriction semantics the realm rework had silently turned into an always-open subtree. Cross-domain ROR origins move to their own RealmConfig.related_origins field — always additive, capped, validated to be outside the rp-id domain, and the sole source of the /.well-known/webauthn document. Admin API POST/PATCH accept related_origins; misfiled entries are rejected (cross-domain in origins, in-domain in related_origins). Admin UI: the realm dialog edits the two lists separately with end-user-oriented explanations (allowed sign-in sites vs. related domains + the well-known note); the Realms section intro explains the multi-domain model, and the table shows sign-in site and related domain counts.	2026-09-06 22:29:12 +00:00
LeoVasanko	cdabc5d9e6	Realm machinery tests: resolution, validation, dispatch, code binding, conversion ... - Registry resolve order (exact rp-id, auth host, related origin, longest suffix), port/trailing-dot normalization, unknown hosts. - Cross-realm validate_config: related-origin cap, auth-host/related collisions, related-inside-other-realm, auth-host vs rp-id. - ASGI dispatch: HTTP 421, realm in scope state, contextvar scoping and reset, WS pre-accept close and cross-realm effective-auth-host rule. - Auth codes bound to issuing realm (set-session and OIDC token). - Legacy conversion stamps credentials/sessions/OIDC with the rp-id. - OIDC key censoring in transaction logs; bootstrap default-realm caveat.	2026-09-06 04:33:08 +00:00