Skip to content

[2.1.8] Username check (sa=usernamecheck) always returns HTTP 403 #9822

Open

Description

@gecifuen

Basic Information

The AJAX username availability check (?action=signup;sa=usernamecheck;xml) always returns HTTP 403 Forbidden.

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

  1. Go to the registration page (?action=signup).
  2. Type any available username in the username field.
  3. 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

Image Image

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:

if (empty($_COOKIE) || empty($_COOKIE[$cookiename]) || empty($_SERVER['HTTP_REFERER']) || stripos($_SERVER['HTTP_REFERER'], $scripturl) !== 0) {
    send_http_status(403);
}

Issues:

  • 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.

Activity

  1. sbulen commented on Nov 3, 2026

    @sbulen
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions