[3.0] Let the registration form ask whether a username is taken - #9486
Merged
live627 merged 1 commit intoAug 11, 2026
Merged
Conversation
The check the form makes as the username is typed answers 403 to everyone it exists for, and 3.0 now treats that as no answer at all. The guard wants Config::$cookiename in $_COOKIE. That is the login cookie, so the only people who get past it are the ones who already have an account. It then does not stop: sendHttpStatus(403) returns, and the XML it was refusing is written out underneath the refusal. 2.1 got away with that because its raw XMLHttpRequest never looked at the status. 3.0's wrapper does - smc_Request.fetch() rejects anything that is not res.ok - so the promise fails, getXMLDocument() calls the callback with false, and the icon beside the field never moves whatever is typed into it. Asks for a session and a referer from this forum, which is what the check was after, and stops when it refuses. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
jdarwood007
approved these changes
Aug 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The registration form's "is this username free?" check has never returned an
answer on 3.0. It has been answering 403 to everybody it exists for, and 3.0
now treats a 403 as no answer at all.
The guard asks for a login cookie.
Config::$cookienameis the login cookie. Somebody filling in the registrationform does not have one — that is what registering is for — so the only people who
get past it are the ones who already have an account.
And it does not stop.
sendHttpStatus(403)returns, and the XML it justrefused is written out underneath the refusal. 2.1 got away with that: its raw
XMLHttpRequestnever looked at the status, so the body came through and thecheck worked.
3.0's wrapper does look:
so the promise rejects,
getXMLDocument()calls the callback withfalse, andcheckUsernameCallback()readsXMLDoc.getElementsByTagName(…)off it andthrows. Whatever is typed, the icon beside the field never moves.
Reproducing it needs a browser, because curl sends no cookies of its own — that
is probably why it has gone unnoticed. In the console on the registration page:
What changes
Asks for a session and a referer from this forum — which is what the check was
after — and stops when it refuses, rather than sending the refusal and then the
thing it refused.
Testing
With this, on the registration page: an unused name turns the icon green with
"Username is available", an existing member's name and a name on the reserved
list turn it red, and typing again puts it back to "Check if username is
available". Clicking the icon asks again on demand. No console errors.
(#9483 is what makes a taken name come back as
valid="0"rather than an errorpage — without it this shows the same red icon, from a parse failure rather than
an answer. Each stands alone.)
Issues References (Fixes|Related|Closes)
Related to #7933