A registration token can now be marked `passwordless`, which will let the
user register without picking a password: their identity is established by
the email verification code instead.
This only adds the column and plumbs it through the storage layer, the
admin API and the anonymous `registrationToken` GraphQL query; the
registration flow itself is unchanged for now.
`/invite/{token}` checks that the token exists and redirects to `/register`
with it in the query string, which hands it to the form island as a read-only
field. Once the token resolves over GraphQL, the username and email address it
was issued for are filled in and locked, and the email field shows up even when
the server would otherwise not ask for one.
The token is passed back in the POST body and attached to the registration.
Nothing validates it server-side yet.
The registration form needs to know, before the user submits anything, whether
the code they were handed is usable and which identity it pins. The query only
returns whether the token is valid and the username and email it was issued
for, never the admin-only details.
Registration tokens now report the `/invite/{token}` deep link alongside the
`username` and `email` they were issued for, and the create endpoint accepts
both. All the token endpoints now take the `UrlBuilder` so they can build that
link.
A registration token can now optionally carry the username and/or the email
address the account it is used for has to be registered with. This only adds
the columns and plumbs them through the storage layer and the CLI; nothing
enforces them yet.
`/register` was a username-first step handing off to
`/register/password`; now that the form checks availability as you type,
that step has nothing left to do. Both pages become one: the island
mounts on `/register` and renders the form, the upstream provider
buttons and the sign-in link, the way `/login` already lays them out. It
mounts even when password registration is disabled, since the providers
now live inside it.
`/register/password` and its `PasswordRegister` route are removed
outright rather than kept as an alias. `RegisterContext` and
`PasswordRegisterContext` become one context, which resolves the
provider URLs and the sign-in link server-side so that the island only
has to render them.
The server-rendered registration form is replaced by a React-based
component which talks to the GraphQL API to validate the username as it
is typed, renders the CAPTCHA in-page, and gives live password
complexity feedback. Server-side validation errors are threaded into
the form through the mount node, so a rejected submission re-renders
with the same messages the old template showed.
Registering now requires JavaScript: the <noscript> block shows a
notice and a sign-in link instead of a duplicate form, which could not
work anyway when a CAPTCHA is configured. While the script loads, the
page shows a skeleton of the form to avoid layout shifts, and a hidden
error notice is revealed if it fails to boot.
Exposes a new query telling whether a given username is available for
registration, and if not, why: already taken, or rejected by the
registration policy. A username reserved on the homeserver side is
deliberately reported as taken, mirroring the ambiguity of the
registration form, which doesn't tell the two apart either.
Because this effectively is a username-existence oracle, the query is
rate-limited per requester, configurable through the new
`rate_limiting.username_availability` option.
The helper parses the mount node's dataset, waits for the i18n setup
before the first render, and swaps the page to a server-rendered error
notice when booting fails. This fixes the account app staying on its
loading screen forever when fetching the locale data fails, and gives
upcoming server-rendered pages with React islands a common entry point.
The new `unused_async_trait_impl` lint flags `async fn` trait impls without any `.await`. The `FromRequestParts` impls that only read from the request parts now return `std::future::ready(...)` directly. The GraphQL module gets a module-wide allow: async-graphql's `#[Object]` refuses non-async resolvers and its `Enum` derive emits async trait impls of its own.
Also drop the `?` on two `return Err(...)?` statements in the introspection handler, flagged by `needless_return_with_question_mark`.
One pinned step now installs pnpm, Node.js and the dependencies. `require-lockfile: true` keeps the `--frozen-lockfile` semantics, `cache: true` keeps the pnpm store cache.
`pnpm/setup` reads the runtime version from `package.json` and ignores `.node-version`. With `onFail: download`, pnpm records Node 24.15.0 in the lockfile and downloads it on every install unless `--no-runtime` is passed. The Dockerfile and the docs build pass it, since they already run a pinned Node. `.node-version` stays for the Cloudflare Pages build, which reads it to pick the Node that bootstraps corepack.
`comment_width = 80` counts the whole line, indentation included, which
wraps far more aggressively than intended; the latest nightly rustfmt
(rust-lang/rustfmt#6802) started enforcing it on comments it previously
left alone. Turn `wrap_comments` off rather than reformat everything.
`max_width = 100`, `comment_width = 80` and `use_small_heuristics =
"Default"` are rustfmt's defaults, so drop them too; only the two
nightly-only import options remain.
The oidc-client integration tests read the real system clock through a
`now()` helper. The ID token builder generates a fresh RSA key before
stamping `iat`, while each test captured its own `now` earlier for
verification. Under coverage instrumentation on a loaded CI runner, the
two key generations in `fail_verify_id_token_wrong_auth_time` took more
than the 5 minute `iat` leeway, so verification failed on `iat` before
ever reaching the `auth_time` check the test asserts on.
Make the helper return a frozen `MockClock` timestamp instead. Every
token and verification in the binary now shares one instant, so setup
duration can no longer affect the outcome, and the clippy opt-out for
`Utc::now()` goes away.
Matrix 1.17 requires servers that don't support the legacy
authentication API to reject `m.login.application_service` on
`/login` with a 400 and the `M_APPSERVICE_LOGIN_UNSUPPORTED` error
code. Previously this login type fell through the generic unsupported
credentials path and returned `M_UNKNOWN`, which appservices written
against Matrix 1.17 can't distinguish from an unrelated failure.
Quentin Gliech