- 'paskia init [rp-id] [rp-name]' and 'paskia migrate [rp-id]' are now
positional; comma separation and the --rp-id/--rp-name flags are gone.
- With an existing paskia.kantadb, init adds the rp-id as a new domain
(seeding its OIDC provider) or updates an existing domain's rp-name.
- Origin allow-list semantics clarified: the bare '*' entry allows
anything within the rp-id domain on any scheme and port (also the
empty-list default and its display in the admin UI, replacing the
synthetic '*.rp-id' row); '*.x' wildcards are https-only; exact entries
match scheme, host and port. Legacy '*.rp-id' wildcards migrate to '*'
to preserve their any-scheme meaning.
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.
- Admin: replace Server Options dialog with per-realm management —
realms table on the overview, add/edit/delete realm dialog backed by
/auth/api/admin/realms/. Origins may be any well-formed origin;
non-subdomain ones are related origins (ROR, max 5) and the dialog
points at the .well-known/webauthn URL that must list them.
Connectivity checks compare against the edited realm's rp-id and
degrade to warnings instead of blocking saves.
- Host mode (limited profile) now keys off own_auth_host so realms
sharing another realm's auth host serve the full profile locally.
- Credential list shows a realm badge on passkeys registered for a
different rp-id than the current realm.
- Profile shows an enrollment prompt when the user has no passkey for
the current realm (e.g. after a cross-realm remote login).
- Remote auth permit shows the requesting realm when it differs from
the approver's own.
- settings cache can be force-refreshed after realm changes.
Allows Paskia to authenticate the user to a client site.
- User friendly client registration flow on the admin app
- Redirect-based authentication flow (per spec)
- Backchannel logout both ways to keep sessions synchronized
- Groups integrated with Paskia's permission system
- Adds email, preferred username and telephone fields on user profile
- All new user basic info layout to show the new information, better looks
- API and DB structures redesigned
- Various unrelated fixes to theming and layout
Add comprehensive remote authentication system allowing users to log in from one device by authenticating from another trusted device. Features include:
- Proof of Work (PoW) protection using PBKDF2-SHA512 to prevent abuse
- Simple pairing codes (3 words) protected by dynamic PoW difficulty
- Autocomplete pairing code input with error checking
- Real-time WebSocket communication between devices
Unlike device addition links and reset links with QR codes that only allow adding an authentication method, and that work offline over the duration of several days, this mechanism is strictly online, with 5 minute time limit.
LeoVasanko