[3.0] External authentication (part 4 of 5) — lets people sign up without a password

[albertlast]

Do not merge without #9492. This is the first thing that creates an account with no password, which makes the User::validateSession() prompt unanswerable — such a member is shut out of the administration and moderation areas permanently. #9492 gives that prompt an answer. See the merge order note on #9381.

Description

Part 4 of 4, on top of #9489. Review #9381, #9488 and #9489 first.

The first three parts all assumed the account was already there. That leaves the
obvious hole: somebody who has never registered here.

• An identity provider vouches for a stranger, SMF sends them to ?action=signup —
  and the form asks them to invent a password, which is the one thing they came
  here not to have. registerMember() hard-errors on an empty one.
• A passkey could not create an account at all. The only way to get one was to
  already have an account and a password to sign in with.

So the two features shipped so far can sign an existing member in, and nothing
more. This closes that.

Accounts with no password. registerMember() gains a passwordless option:
it skips the "you must choose a password" error and stores an empty passwd.
Nothing hashes to an empty string, so no password can ever match it — that is
the marker User::hasUsablePassword() has looked for since part 1. The option
is never read from the request; only a caller that has already arranged some
other way in asks for it.

The sign up form. When a provider has vouched, the username and email are
filled in from the claims, the password boxes are gone, and the form says who
vouched. When passkeys are offered, a button appears beside the password boxes;
pressing it runs the creation ceremony there and then, the verified credential
waits in the session, and the boxes are replaced. The button is added by the
script, so a browser without the API never sees a dead control and still gets
the ordinary form.

Nothing is created behind anybody's back. Being vouched for gets you to the
sign up form and no further: the agreement, the privacy policy, COPPA, the
verification image and admin approval all still apply, which is the whole reason
this hands over to the ordinary form rather than inserting a row. The credential
is attached after registerMember() returns an ID, and if the member never
finishes, it is forgotten with the session.

One wrinkle worth knowing about. A passkey made before the account exists
has no member ID to derive its WebAuthn user handle from, so it carries a random
one. That handle is stored with the credential and reused by every passkey the
member adds later — otherwise the browser would group them separately and show
one account as two.

New setting, on Admin → Server → Authentication → Passkeys:
webauthn_allow_signup, off by default. Letting members add a passkey to an
account they already have is a smaller decision than letting an account exist
with no password at all, so it is a separate box. The OIDC side already had
allow_registration per provider, from part 2; AuthExternal now also checks
whether the forum is taking new members at all, so a closed forum says so
instead of bouncing them to a form that refuses them.

Recovery. An account with no password is recovered the way every SMF account
is: the emailed reset at ?action=reminder, which turns it into an ordinary
account with a password. Worth flagging that that path is broken on release-3.0
today and #9380 fixes it — it matters more once accounts can exist with no
password to begin with.

Not changed: admin-created accounts still get a generated password, and the
welcome emails are untouched (none of the guest-facing templates prints
{PASSWORD}; a customised one that does would get an empty string).

How this was tested

No test suite, so this was driven over real HTTP against the Docker environment,
with a forged authenticator standing in for navigator.credentials and a real
Keycloak standing in for the provider. 76 checks, all passing.

Passkey sign up (45 checks):

• the form offers the passkey and hides the offer until the script decides
• the ceremony returns options naming this forum, a 32-byte handle and a
  discoverable credential
• nothing is written to member_auth before the account exists
• the form afterwards drops the password boxes and says the passkey is ready
• the account is created with passwd = '' and a salt, activated, and signed in
• the credential is attached to it, under the hashed credential ID, with the key
  and the handle kept
• the passkey then signs them in from a fresh browser
• a second passkey added from the profile reuses the sign up's handle and
  excludes the first
• '', the username and password are all refused as passwords
• an ordinary password sign up still works and still gets a password
• refused: no username, no session token, a signed in member, the setting off

OIDC sign up (31 checks):

• the provider button, the authorize redirect, the provider's own login form and
  the callback
• lands on the agreement, then a form with the username and email filled in from
  the claims, no password boxes, and Keycloak named
• no account created until the form is submitted
• the account is created with no password, and the identity attached to it
• coming back a second time signs them straight in, with one account, not two
• passwords still refused; the reminder page does not fall over on an account
  with no password
• with allow_registration off, no sign up form and a message that says why

smf_log_errors held only the deliberate refusals afterwards. composer lint,
phplint, and the index/licence/EOF/languages checks are all clean, and the
forum was put back the way it was found.

Issues References (Fixes|Related|Closes)

Related: #9381, #9488, #9489, #9380