Parse-server: Email field in _Users is not unique preventing upgrade to 3.5.0

[ArMouReR]

In our server email field is not unique. This is intentional behavior that was implemented a few years ago in order to host on the same db and server multiple Apps.
The only unique field is username that contains App id as part of the string.

Parse server on init trying to create email_1 index with following parameters:
db.getCollection("_User").createIndex( { "email": 1 }, {name: "email_1", sparse: true, background: true, unique: true } )

In our case we need to change unique: to False.

Can you please guide me how to change the code to remove this enforcement ?

Can it be added as feature request if someone else also interested in this feature ?
I am ready to work on PR...

Thanks !!!

• Server

  • parse-server version 2.3.7 moving to 3.5.0
  • Operating System: Amazon Linux
  • AWS

• Database

  • MongoDB version: 4.2
  • Storage engine: wiredTiger
  • AWS

Logs/Trace

errmsg: 'Index with name: email_1 already exists with different options'

[davimacedo]

Unique email index has been in place since Parse 2.3.0 and there is a guide here. I believe it was something planned by design. I don't know exactly the reason and I'm not sure if a PR turning this index optional is a good idea. Maybe @acinader can help here.

[santiagosemhan]

It's not a common case to have not unique emails. Maybe If it turns optional, it could lead to security bugs.

[ArMouReR]

Can we make it part of configuration ? e.g. by default it will be turned on, but can be disabled in case that someone need it ?

[davimacedo]

At a first glance I don't see any problem in turning it optional.

[ArMouReR]

Does it needed for anyone except me ?

Meanwhile as I am running on AWS elastic beanstalk, so, I am posting here a quick hack that I did, just in case that any one will land here from Google:

This file should be placed inside .ebextensions:
remove_uniqueness_check_for_email.config

files:
  "/tmp/remove_uniqueness_check_for_email.sh":
    mode: "000755"
    owner: root
    group: root
    content: |
      #! /bin/bash
      # Loading environment data
      # EB_APP_CURRENT_DIR='/var/app/current/'
      # Remove uniqueness check for email column in _Users table
      # Multi line match
      # https://unix.stackexchange.com/questions/264344/how-to-replace-a-multi-line-code-with-sed
      # sed "/const\semailUniqueness/,/\})\;/{          # in this range
      # /.*/d                               # delete all characters
      # }' infile                       
      find ./node_modules/parse-server/ -name 'DatabaseController.js'  -exec sed -i "/const\semailUniqueness/,/\})\;/{/.*/d}" {} +
      find ./node_modules/parse-server/ -name 'DatabaseController.js'  -exec sed -i "s/emailUniqueness,//g" {} +
container_commands:
  01remove_unneeded_file:
    command: "sh /tmp/remove_uniqueness_check_for_email.sh"

These two sed call are patching DatabaseController.js by removing call to ensureUniqueness on email column.

[mtrezza]

How do you reset a password if the email field is not unique to a user?

[ArMouReR]

Our username build from user email and App id, something like [email protected]&&app_01.
So, when we are looking for password recovery we are adding App id and looking for username build in this way. If such row is present in database we are sending password recovery email.

[acinader]

Do we think anyone else would want this?

@ArMouReR why not just move the email to a new field without an index and do the same thing you do for username to email (ie add the appid)? Seems a lot easier than what you’re doing with eb and proposing here?

[mtrezza]

Our username build from user email and App id, something like [email protected]&&app_01. ...

Seems like an almost hacky edge case. I don’t see a benefit for the community with this change. It is also contrary to the usual authentication paradigm. A concept that comes close to what you seem to pursue is sub-user management, but that is a different approach. Maybe rethink your authentication model.

Modifying DatabaseController.js with .ebextensions is also something I would rethink. This is super hacky and far from reliable. Rather deploy your forked version of parse server. It also has the advantage that you can run the tests on your fork and see if you break anything you did not anticipate.

_{Sent with GitHawk}

[ArMouReR]

@acinader You right, if we would do this change today this is what we would do, but unfortunately 2 years back we didn't realized that email must be unique. And now our database is missing data in email field and we do have, as you suggested, "new" email field without index and we need to cope with it.

@mtrezza Thanks for your suggestion, didn't think about running tests, we will check this out. And, yes, I know it's hacky, but it was quick and dirty solution that helped on that stage.

[mtrezza]

@ArMouReR this issue can be closed I take it?

_{Sent with GitHawk}

[ArMouReR]

Yes, thanks for everybody for help !