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
Today, you cannot register as USERNAME if someone else already registered as username. Most of the codebase now enforces case-insensitive username uniqueness. Account login is one of the few places that is still case-sensitive to usernames. If you registered as Username then you cannot log in as username. This is problematic for a couple of reasons:
Users may not be aware of the exact casing they used for their usernames during initial registration
Users typing on a phone or smartwatch are less likely to be precise about their capitalizations.
For example, phones and wearables auto-capitalize the first letter of an input field by default, which may cause confusion when a user's login fails because their username starts with a lowercase character
Caveats
Even though new account usernames cannot collide with existing account usernames, I acknowledge there's a chance that username collisions might exist from before this constraint was implemented. We can't naively say that all usernames are currently case-insensitively unique. Unless there has been some server backfill to address this, there are undoubtedly a small handful of colliding usernames. I'd bet there are users with the usernames bob and Bob.
However, it should be possible to use case-insensitive logins when there is exactly one user with the "same" username, then fallback to case-sensitive logins when there are multiple users with the "same" username.
For example:
If I am the only user with some permutation of the username Unique then I should be able to log in using unique or UNIQUE or uNiQuE.
If there is a user named collision and another user named COLLISION, then both of these users should follow the existing login behavior and should only be able to log in using their case-sensitive username. A login attempt with the username Collision should always fail because it's ambiguous which user model should be retrieved.
Affected Platforms
Description
Today, you cannot register as
USERNAME
if someone else already registered asusername
. Most of the codebase now enforces case-insensitive username uniqueness. Account login is one of the few places that is still case-sensitive to usernames. If you registered asUsername
then you cannot log in asusername
. This is problematic for a couple of reasons:Caveats
Even though new account usernames cannot collide with existing account usernames, I acknowledge there's a chance that username collisions might exist from before this constraint was implemented. We can't naively say that all usernames are currently case-insensitively unique. Unless there has been some server backfill to address this, there are undoubtedly a small handful of colliding usernames. I'd bet there are users with the usernames
bob
andBob
.However, it should be possible to use case-insensitive logins when there is exactly one user with the "same" username, then fallback to case-sensitive logins when there are multiple users with the "same" username.
For example:
Unique
then I should be able to log in usingunique
orUNIQUE
oruNiQuE
.collision
and another user namedCOLLISION
, then both of these users should follow the existing login behavior and should only be able to log in using their case-sensitive username. A login attempt with the usernameCollision
should always fail because it's ambiguous which user model should be retrieved.Additional Notes
The reason I'm posting this as a GitHub issue is because I already have a PR fix up.
The text was updated successfully, but these errors were encountered: