[Security] Stored XSS via User Name in Dashboard

[Alok-2005]

Description
There is a critical security and data integrity issue where the Sugarizer Server accepts malicious usernames during the signup and update processes.

This leads to two major problems:

• Stored XSS: Malicious scripts injected as usernames are executed in the context of the Administrator/Teacher Dashboard.
• Inconsistent State: During signup, even if the creation process encounters errors due to a malicious name, a partial user record is often still stored and displayed in the Dashboard user list.

The server should validate and sanitize usernames to align with the core application's security requirements.

Steps to Reproduce

• On Signup: Perform a signup via the API using a malicious name (e.g., <script>alert('XSS')</script>).
  => Observe that even if the client indicates a failure, the name appears in the Dashboard's user list.
• On Update: Update an existing user's name to a malicious payload via the API.
  =>Observe that the name is updated successfully and the script triggers immediately when an admin views the user list or journal on the Dashboard.

Expected Behavior

• The server should validate usernames during both signup and update API calls.
• If a name contains illegal characters or script tags, the server must reject the request and return an "Invalid Username" error
• Malicious usernames should never reach the database

[llaske]

It look like it's not possible from a Sugarizer client to create then login with a XSS string but the user is created on the server with the XSS string.

Capture.video.2026-02-15.10.38.01.mp4

[llaske]

Fixed in #419