Blocked usernames with special characters are not enforced and registration UI does not display error

[sahillllllllll-bit]

Description:

When a username containing special characters (such as ., +, or *) is added to the BlockedUsernameList, it is not properly blocked during registration.

For example, if john.doe is added to the blocked username list, a new user is still able to register with the username john.doe. However, usernames without special characters (e.g., john or admin) are correctly blocked.

After fixing the backend matching logic, the server correctly returns an error-blocked-username response. However, the registration UI does not display any error message to the user. The error appears in the browser console and network response, but no toast or validation message is shown on the registration page.

So currently there are two related problems:

1. Blocked usernames containing special characters bypass validation due to incorrect regex handling.
2. Even when the backend correctly blocks the username, the registration UI does not surface the error message to the user.

This results in inconsistent validation behavior and a confusing user experience during registration.

Steps to reproduce:

Part 1 — Blocked Username with Special Characters Is Not Enforced

1. Go to Administration → Accounts.
2. Add john.doe to the BlockedUsernameList setting.
3. Save the changes.
4. Open a private/incognito window.
5. Attempt to register a new user with the username john.doe.

Result

The user is successfully registered, even though john.doe is present in the blocked username list.

---

Part 2 — Error Not Displayed in Registration UI (After Backend Fix)

1. Apply the backend fix so that blocked usernames with special characters are correctly detected.
2. Restart the server.
3. Ensure john.doe is still present in BlockedUsernameList.
4. Open a private/incognito window.
5. Attempt to register a new user with the username john.doe.

Result

• The network response returns:
  • success: false
  • errorType: "error-blocked-username"
• The error appears in the browser console.
• However, no error message or toast is displayed in the registration UI.

Expected behavior:

1. If a username is added to BlockedUsernameList, it should be blocked during registration regardless of whether it contains special characters (e.g., ., +, *).

2. Usernames such as john.doe, sahil.dev, or any other entry explicitly listed in the blocked username setting should not be allowed to register.

3. When a blocked username is entered during registration, the UI should display a clear error message (e.g., "<username> is blocked and can't be used") instead of failing silently.

4. The behavior should be consistent for:

   • Usernames with special characters
   • Usernames without special characters
   • Real-time validation and final form submission

Actual behavior:

1. When a username containing special characters (e.g., john.doe) is added to BlockedUsernameList, the username is still allowed during registration. The blocked list is not enforced for usernames containing regex special characters.

2. After fixing the backend validation logic, the server correctly returns:

   • success: false
   • errorType: "error-blocked-username"

   However, the registration UI does not display any error message to the user.

3. The error is visible in the browser network response and console, but no validation message or toast appears on the registration form. The form remains unresponsive from the user's perspective.:

Proposed Fix

This will be handled in two separate PRs:

PR 1 — Backend Fix

• Remove double escaping in usernameIsBlocked.
• Ensure blocked usernames with special characters (e.g., ., +, *) are correctly enforced.

PR 2 — Frontend Fix

• Properly handle error-blocked-username in the registration form.
• Display a clear validation error instead of failing silently.

The changes are split to keep backend validation logic and frontend UI handling independent and easier to review.

[sahillllllllll-bit]

@ahmed-n-abdeltwab please take look at this :)

[ahmed-n-abdeltwab]

@ahmed-n-abdeltwab please take look at this :)

sure, no problem

[ahmed-n-abdeltwab]

ohh I see what's going on. You need someone to review, but unfortunately, I don’t have the code access required to help you directly. You should advertise your PRs and issues in the public frontend channel

[sahillllllllll-bit]

ohh I see what's going on. You need someone to review, but unfortunately, I don’t have the code access required to help you directly. You should advertise your PRs and issues in the public frontend channel

thanks for response,
I just wanted a quick check on whether the issue is valid and if my implementation is correct, or if I need to change anything.

[ahmed-n-abdeltwab]

ohh I see what's going on. You need someone to review, but unfortunately, I don’t have the code access required to help you directly. You should advertise your PRs and issues in the public frontend channel

thanks for response, I just wanted a quick check on whether the issue is valid and if my implementation is correct, or if I need to change anything.

that makes sense. However, you'll need a maintainer to confirm whether this is a bug or a feature. To the best of my knowledge, this definitely seems to be a bug

[Rahulyadavv123]

@d-gubert , @sahillllllllll-bit , @MartinSchoeler can anyone please assign me this issue , i know how to fix this .. , thannks