Skip to content

[3.0] Reserve the names on the reserved names list - #9484

Open
albertlast wants to merge 1 commit into
SimpleMachines:release-3.0from
albertlast:3.0/reserved-names-separator
Open

[3.0] Reserve the names on the reserved names list#9484
albertlast wants to merge 1 commit into
SimpleMachines:release-3.0from
albertlast:3.0/reserved-names-separator

Conversation

@albertlast

Copy link
Copy Markdown
Collaborator

Description

A fresh 3.0 forum reserves nothing. Admin, Webmaster, Guest and root are
all free to register, and so is anything an admin adds afterwards — until they
open Registration → Reserved Names and press Save, which is the only thing that
ever writes the setting properly.

The stored value on a fresh install:

$ mysql -e "SELECT HEX(value) FROM smf_settings WHERE variable='reserveNames'"
41646D696E5C6E5765626D61737465725C6E47756573745C6E726F6F74
                ^^^^                ^^^^         ^^^^

5C6E is backslash-n, two characters, not a newline. checkReservedName() does
explode("\n", …) and gets one element back: the whole list as a single name
that nobody would ever type.

Where it comes from. The default is a language string that spells its
separators that way:

$txt['default_reserved_names'] = 'Admin\nWebmaster\nGuest\nroot';

2.1 fed that straight into an SQL literal — plain '…' for MySQL, E'…' for
PostgreSQL — and both engines turned the escapes into newlines on the way in.
3.0 defines its schema in PHP and inserts the value as a query parameter, so
nothing unescapes it. The strtr() in Table.php that survives from 2.1 only
turns \n back into \n; it was compensating for the escaping that the SQL
literal then undid, and there is no SQL literal any more.

Why nobody noticed. Admin/Registration.php has carried
str_replace('\n', "\n", …) since 2.1, so the textarea splits the list onto
separate lines and it looks exactly right. It has just never been in force.

What changes

Seeds real newlines, so a new install is correct.

Reads either form in checkReservedName(), so a forum that is already installed
starts enforcing its list without the admin having to go and re-save a page they
have no reason to think is broken. That is also why this needs no migration.

Testing

On a forum installed before the change, ?action=signup;sa=usernamecheck;xml:
root, Webmaster and Guest come back valid="0"; r00t and zzznewuser
come back valid="1". Submitting a registration as Webmaster is refused with
the name in the error box. A name not on the list registers as before.

(Read together with #9483, which is what makes the refusal a valid="0" rather
than an error page. Each stands alone.)

Issues References (Fixes|Related|Closes)

Related to #7933

A fresh forum reserves nothing. Admin, Webmaster, Guest and root are all free to
register, and so is every name an admin adds afterwards until they open the
settings page and press Save.

The default list comes from a language string that spells its separators as the
two characters backslash and n. 2.1 fed that into an SQL literal, where both
MySQL and PostgreSQL's E'' turned them into newlines. 3.0 defines its schema in
PHP and inserts the value as a query parameter, so nothing unescapes it and the
whole list is stored as one name that nobody would ever type. checkReservedName()
explodes it on "\n" and gets a single element back.

The admin page has carried its own str_replace for this since 2.1, so the list
has always looked right in the textarea while none of it was in force.

Seeds real newlines, and reads either form, so a forum already installed is
fixed without having to touch its settings.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
@jdarwood007 jdarwood007 added this to the 3.0 Alpha 6 milestone Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants