You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This breaks the real-time username validation on the registration page (the JavaScript treats any non-2xx response as an error and does not update the UI).
The same functionality works correctly in SMF 2.1.7.
Steps to reproduce
Go to the registration page (?action=signup).
Type any available username in the username field.
Observe the network request to index.php?action=signup;sa=usernamecheck;xml;username=...
Expected result
The XML response + HTTP 200
Actual result
The XML response + HTTP 403
Version/Git revision
2.1.8
Database Engine
MySQL
Database Version
10.11.14-MariaDB-0ubuntu0.24.04.1
PHP Version
8.5.12
Logs
Additional Information
Root cause:
In Sources/Register.php, function RegisterCheckUsername(), this new block was added in 2.1.8:
On the registration page, the visitor is usually not logged in, so the SMF session cookie ($cookiename) is missing. This triggers the 403 even when the request is legitimate and the Referer is correct.
If the empty($_COOKIE[$cookiename]) verification is removed, the usernamecheck sub-action works properly again.
I can confirm this, & I think the analysis is correct. I can see the 403s in the console, and yes, it's because the SMF cookie isn't set yet.
BUT...
What's odd is that the users end up getting created. My site gets multiple new users a day. It's working fine.
So, whatever the 2.1.8 change was trying to accomplish isn't working - even if the 403 is issued, it doesn't stop anything. I think that particular edit needs to be rethought. I suspect the blank referer check is intended to fend off bots, but as we can see, it's not stopping anything.
Activity
sbulen commentedon Nov 3, 2026
I can confirm this, & I think the analysis is correct. I can see the 403s in the console, and yes, it's because the SMF cookie isn't set yet.
BUT...
What's odd is that the users end up getting created. My site gets multiple new users a day. It's working fine.
So, whatever the 2.1.8 change was trying to accomplish isn't working - even if the 403 is issued, it doesn't stop anything. I think that particular edit needs to be rethought. I suspect the blank referer check is intended to fend off bots, but as we can see, it's not stopping anything.