Username/email uniqueness is case-sensitive

[rihadavid]

Issue Description

Let's say there is a User with username elonmusk and email elon@musk.com. The problem is, that another user can create another account, with username ElonMusk and email Elon@Musk.com.

The username uniqueness case-sensitivity might be a feature, not a bug, I don't know. But I think it should be case insensitive. For example, twitter.com/elonmusk is the same Musk as twitter.com/ElonMusk and this is how it works on most apps, I think.

However, the email uniqueness case-sensitivity is obviously a bug, because elon@musk.com and Elon@Musk.com is the same email address, which means that more users can have the same email, which means it is not unique.

Steps to reproduce

Just create two Users in the dashboard and try filling the same email/username. It throws an error. Now try with different capitalization. It works.

Expected Results

When defining username or email field, it should check that there is no user with the same username or email, regardless of letters capitalization.

Actual Outcome

It allows creating another user with the same username/email, just different letter capitalization.

Environment Setup

• Server

  • parse-server version: 2.5.3
  • Operating System: WINDOWS
  • Localhost or remote server: LOCAL

• Database

  • MongoDB: MLAB.COM

Maybe @drew-gross could be interested in this issue?

Thanks!

[flovilmart]

We should probably lowercase it all! Not sure how it was implemented in parse.com. We could also simply update the queries for case insensitive comparison. What would you prefer?

[montymxb]

Just a note it's not completely guaranteed that the local part (before the @) is case insensitive. A quick mention of this is in this so post.

This is more just a thing to be aware of though. It's generally better practice to just lower case them all, since pretty much all addresses are case insensitive nowadays. It's kind of a weird situation but I would be on the side of it's 'safe to assume' that most are case insensitive. Plus it helps preventing duplicates like mentioned above 👍 .

[flovilmart]

So moving forward, the resolution is 3 fold:

1. make all queries with regexp case insensitive for username and email
2. make all emails fields always lowercase in read / write operation
3. find a solution for the username? Store as is, but query with 1?

[sirnacnud]

What is the status on this issue? I actually had a user create two accounts with the same email and username, but the case is different. This is fairly easy to do when the keyboard automatically capitalizes the first letter on text input fields (iOS does this).

[montymxb]

@sirnacnud We haven't been working on this lately. Although it is something we are still aware of, we're focusing on other issues at the moment. That being said we are always open to someone taking the initiative and putting up a PR. We can always help guide things from there.

[JacobJT]

We've had some issues with password resetting based on case-sensitivity. We use the e-mail as the username, as well, but force it to lower case to maintain uniqueness. We left the e-mail alone as we did not know if it is really safe to tamper with what is entered. It seems that's a fairly acceptable solution, though? I think the case sensitive e-mail field we currently have affects more people than would be affected by casting to lower case.

Or should we store as input by the user and expect an eventual update that queries case insensitively?

[gnu-lorien]

I continue to be affected by this issue. Interestingly part of how I realized that it was a case sensitivity issue is because parse dashboard searches fields in a case insensitive manner.

[flovilmart]

We laid out a plan for the fix but didn’t get a chance to provide it. Are you willing to give a PR for it?

[macklus]

Complex problem, sadly.

First, i just apply .toLowerCase() on all users, before save it. Users complain ¿...? Second, i use query.matches('username', username, 'i'), but its to slow. Finally, only functional option is set username_lc to username.toLowerCase() and use it to search with equals.

[flovilmart]

First we can make all queries case insensitive, I’m not for storing additional data

[macklus]

@flovilmart sure it is better solution than mine. I just comment my scenario and how i solve it, just for info if any can use it before PR fix.

[farhan-syed]

Is there a way to currently achieve this?

[rolandvar]

So moving forward, the resolution is 3 fold:

1. make all queries with regexp case insensitive for username and email
2. make all emails fields always lowercase in read / write operation
3. find a solution for the username? Store as is, but query with 1?

Another solution could be give the possibility to enable the mongodb unique index on the email field, what do you think about it?

[flovilmart]

The email is already unique and sparse, the problem is the case sensitivity.

[georgesjamous]

It doesn't make sense to have emails with capitalized letters as they do not matter in an email address. I believe performing a case-insensitive query to validate emails is just masking the real problem, which is "Failing to properly store email addresses" (in lowercased letters, as they should be).

Forcing all emails to be lowercased is far better than using a case-insensitive query, in speed and and overhaul database consistency.

Developers with existing users should probably migrate all account emails to lowercase, make sure to lowercase all emails before signup, and use a beforeSave hook to patch this untill a pull request kicks in.

[flovilmart]

doesn't make sense to have emails with capitalized letters as they do not matter in an email address.

that’s your opinion, I believe if a dev wants to perform sanitation/ lowercase etc... this can and should be done in a hook.

In the end. I’m not sure we should perform anything on the database indexation side.

Mixed case usernames can be a feature one developer want.

Overall, as no one is picking this up for implementation, workarounds are available (through hooks), i’ll be closing.

If one wish to implement one of the suggested resolutions, feel free to open a PR.

[acinader]

A failing test to get started.

I am not sure how to handle OAuth connected users (and anonymous) which will need to allow usernames that would be a duplicate if evaluated case-insensitively.

I'm gonna get started on how I would handle in a before save hook. Any input greatly appreciated ;).

[acinader]

I've just pushed a solution to the failing test.

I'm going to discuss it on the PR, so see #5634

@flovilmart if you've got the bandwidth, I'd love a guest pr

[flovilmart]

I don’t have any bandwidth, sorry

_{Sent with GitHawk}