`POST /register` checks that a registration matches the username and
email address its token pins, but the token step could attach any valid
token to a registration afterwards. Registering as anyone, then
attaching a pinned token, registered a username the token doesn't pin.
Swapping a passwordless token for one that isn't left a registration
with no password at all.
The token step now refuses a token that doesn't fit the registration:
one that pins another username or another email address than the
registration's, or one that isn't passwordless for a registration
without a password or an upstream link. Finishing a registration checks
the same against the verified email address, and refuses a passwordless
registration without one. Only a tampered registration gets that far,
so these fail like the other last-minute checks there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CZdGaj9bJcn5QeeUw8YXoF
`/register?token=…` now resolves the invite code server-side and hands what it
was issued for to the form island through a `data-invite` attribute: a pinned
email address is shown as the line announcing where the verification code goes
rather than as an input, a pinned username isn't shown at all, and a
`passwordless` code replaces the password fields with a notice and relabels the
submit button. A code the server refused only reports that, as an error above
the form.
Because a passwordless code is a way to register on its own, the shortcuts
which send the page to the upstream provider or to `/login` when password
registration is disabled are skipped when the link carries one.
The code itself travels back on submission through a hidden field, so a form
which comes back with errors keeps its shape, and so does the redirect the page
sends the user to when the CSRF token has expired.
The registration form can now carry an invite code, in a hidden `token` field,
and the code is resolved before anything else, so that:
- an unknown, revoked, expired or exhausted code is rejected with an error on
the field, and re-rendering the form keeps the code
- a code which pins a username or an email address only lets that identity
register, an empty field meaning the user accepted what the code pins
- a `passwordless` code skips the password entirely and requires an email
address to verify, even when the server otherwise doesn't, and is a way to
register on its own when password registration is disabled
The code is also consumed whenever one was used, not only when the server
requires one.
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 and the
admin API; the registration flow itself is unchanged for now.
Registration tokens now report the `/register?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, and `Register` carries the token in its query string.
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.
The server-rendered registration form is replaced by a React island mounted
on `/register`, which renders the CAPTCHA in-page, gives live password
complexity feedback, and lays out the upstream provider buttons and the
sign-in link the way `/login` does. The island owns the whole form, so every
variant of the page is rendered from the mount data alone, and the user fills
it in one step. Server-side validation errors are threaded back into it
through the mount node, so a rejected submission re-renders with the errors
attached to the fields they belong to.
`RegisterContext` resolves the provider names and the sign-in link server-side
so that the island only has to render them. The sign-in link is derived from
the post-auth action in the query string instead of the `PostAuthContext`
loaded from the database, which drops a round trip from both the GET and the
invalid-form re-render.
Registering now requires JavaScript, including on the variant with upstream
providers only and on the one without a CAPTCHA: the <noscript> block shows a
notice 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. The server-rendered CAPTCHA component and its entrypoint are removed
with their only consumer.
The page imported it on its own as well, which is what broke the CAPTCHA rendering fixed by #5992 on the old password registration page. Also test that the page renders with a CAPTCHA configured.
The registration page had two steps: `/register` picked between a password
and an upstream provider, then `/register/password` collected the username,
email and password. Both now live on `/register`, whose `POST` handler runs
the provider branch first and otherwise hands the form to the registration
body, which stays in `password.rs` as a helper.
The page renders the username, email, password and terms-of-service fields,
the captcha and the provider buttons in a single form. The provider buttons
submit that same form, so they are marked `formnovalidate` to skip the
validation of the fields they do not use, and come after the primary submit
button so that Enter still registers.
`/register/password` is gone; a `GET` on it redirects to `/register` with the
query string it was given, so bookmarks and links keep working. Its
`?username=` prefill has no producer left and is dropped.
`GET /register` now renders the page whenever password registration is
enabled, instead of redirecting to `/register/password` when there is no
upstream provider. Without password registration, a single provider still
gets redirected to directly, and no provider at all now redirects to
`/login`, where `/register/password` used to send that case.
An unknown or disabled provider gives a 404 through an inline `GenericError`
rather than the route-wide `RouteError`, and an expired CSRF token on the
password path now sends the user back to `/register` instead of failing the
request.
The registration page is about to render the password registration form
itself, so its context needs the form state and the captcha configuration
`PasswordRegisterContext` carries today.
