Auth unique email

[dylankuipers]

Link to reproduction

Not relevant

To Reproduce

User collection with "auth: true" and have multiple projects in the same Payload instance.

Describe the Bug

Hi, so I am using a plugin for Payload to have multiple projects in one Payload instance. I use the tenancy plugin for this (1). With this plugin you can have the user's accounts for each project in the same collection, but with a different tenant ID.

I have noticed that while using this plugin, it is impossible to have an account with the same email. Imagine you have two projects and they both have their own website. Right now if you were to make an account on both websites with the same email it is impossible to do. This is because payload forces the email to be unique while using "auth: true" in the collection. As this forces an email and password field.

I have tried to overwrite the email field and set the unique value to false. Though I haven't been successful. I would like to make a custom check myself to check whether the email is unique per tenant ID (from the tenant plugin). Although, I am unable to create this check since payload forces the email field to be unique while using "auth: true". And as far as I know it is impossible to overwrite. It would be ideal if there is a way to turn the unique email field off or if I were to be able to overwrite it.

We have tried reporting this issue to the plugin creator (2), without success, we decided to make an issue for payload instead.

(1) Multi tenant plugin: https://github.com/joas8211/payload-tenancy
(2) Issue at plugin: joas8211/payload-tenancy#23

Payload Version

1.15.6

[ChrisGV04]

Hey @dylankuipers! I believe that the email being a unique field is actually the best thing to do overall, because when you log in, you need to be able to find the correct document for that email which contains the password.

If you allow multiple users with the same email, now you can't identify which website's user account to actually log in as.

In my opinion, to allow that kind of behavior you should create a custom authentication strategy that uses both email and website to identify the correct user and log in to the appropriate website. That way, you could send the website as part of the log in fields or read it from the HTTP headers.

{
  "email": "[email protected]",
  "website": "website1.com",
  "password": "password"
}

Forcing unique: true on the email is not a bug nor an issue, but rather a strategy that's best suited for most use cases. Maybe you can try creating custom authentication strategy.

[dylankuipers]

Thanks for your response @ChrisGV04,

If you're using the tenancy plugin it automatically creates a custom ID for each of your tenants that is also displayed in the user collection. I would use that to determine which site someone is trying to log in to. Although, I am unable to do this as the email field is forced unique. (Which also pretty much makes the plugin useless as people wouldn't be able to make accounts on two different websites of yours)

The only way to go around this is to make a new instance of Payload for each of your websites, but this costs money and makes things more complicated. As now you have to manage multiple instances rather than just one.

I realised this isn't a bug after posting so my bad about that. And while I do agree with you that I could make a custom authentication strategy, I can't really do that. As the plugin forces one of the collections to be auth: true to determine which collection to add the tenant ID to, but if you have auth: true it forces the email field. Unless if I were to make a separate collection for the users & admins?

[silveltman]

I would think that something like the following would be possible:

const collection: CollectionConfig = {
  slug: 'users',
  auth: true,
  fields: [
    {
      name: 'email',
      unique: false
    }
  ],
};

I would expect this to be possible based on the nature of payload OR if not possible a TS error would be nice. Not a bug though indeed.

[DanRibbens]

The right way to do this would be to have a relationship field in your users collection with relationTo sites and have your access control be updated to accomodate it that way. If you need to have a role for each site, you would do so by adding an array with a role(s) select field and site relationship field.

I'm going to convert this to a discussion unless we're overlooking something that is an actual bug to solve. Please feel free to continue discussion.

[silveltman]

@DanRibbens The problem here is that it would not allow users (or customers) to create their own account on different sites within the same payload instance. For example, 3 ecommerce site tenants with frontend registration/login would not be possible

[DanRibbens]

I see, so you want multi tenanancy and use the built-in auth strategy.

I can think of two options:

1. define your own email field on your users collection. As long as you have a top level field with name: 'email', on an auth collection it will override the email field from Payload that defaults to unique. Then you may want add another field to specify the tenant site that account is for and add a composite unique index so that each site user email is unique if you wanted.

2. add one auth enabled collection for each tenant. This option probably only makes sense if you need to enforce uniqueness or have extra site specific user properties to track or you need uniqueness on other fields.

[silveltman]

1. This does not seem to work. The first field in my collection is:

{
  name: 'email',
  type: 'email',
},

And I get this validation message when trying to add a entry with the same email: 'A user with the given email is already registered'

It looks to me like the custom email field is not being used, since the email field is still displayed in the payload auth styles gray box:

[DanRibbens]

@silveltman can you do me a favor and look for and delete the unique index on your users collection in the database or drop the collection and try again?

Those indexes are made for you by Payload on server start but it doesn't delete indexes for you for mongodb.

With that index gone it will let you create more users with the same email.

[silveltman]

@DanRibbens I created a completely new collection with auth enabled and with the following field from the start:
{ name: 'email', type: 'email', required: false, },
Still same validation error: A user with the given email is already registered`.

[silveltman]

I see even more benefits of being able to disable email being unique, that have nothing to do with the tenancy plugin.

It would allow us to create guest users with only an email. For this to work we would also need to be able to set password to not required. This would allow us to manually create users/customers with the details we have about them (maybe address etc) without the customer having to create an account.

Also, for ecommerce this would allow us to create a customer doc in which we store the customers cart. How we currently do this is by creating a random guest account with a random email and password en behind the scene change the email/password when the user "creates an account" while still being logged in the guest account.

If there is a better alternative, please let me know!

[joas8211]

For eCommerce I'd do the "customers" and "users" as different collections and have relation between them. That way you can have a customer registry without them being registered as an user, and if they do register combine the customer with the user.

[silveltman]

@joas8211 that sounds like e good idea indeed.

What do you think of 3 collections; Users, Customer and Guests, where both users and customer have auth enabled?

It would keep users and customers separate, preventing customers from being able to log into the admin panel & preventing users from having a cart.

On the other hand, it does require some manual JWT token stuff I think.

Do you have with this and see things I'm missing?

[DanRibbens]

I've got an update that this is not as easy as I had thought. I tried to do this on my own and ran into some trouble that makes it not currently feasible.

I thought we were using the unique config option and relying on the db constraint. Instead the unique user logic is here: https://github.com/payloadcms/payload/blob/main/packages/payload/src/auth/strategies/local/register.ts#L23

Not only is that written into the register function, the built-in auth needs to have unique email fields or we would need to disable the workflow for forgot password / reset password or change it to somehow work with more than one user record.

I think for anyone needing this you'll need to create a custom auth strategy or make it into a Payload plugin. Alternatively if we can navigate the issues involved here I'd entertain merging in a PR.

There might be another workaround solution to this like adding a user scoping config option or function that can act as a filter on the user results that then a where query can be used when registering, resetting passwords or logging in to get around uniqueness.

What do we think?

[joas8211]

There might be another workaround solution to this like adding a user scoping config option or function that can act as a filter on the user results that then a where query can be used when registering, resetting passwords or logging in to get around uniqueness.

Implementing unique constraint function might be useful in other situations also where uniqueness of a document is combination of multiple fields. I might want to take a look today if I can come up with a generic solution for uniqueness on multiple fields and apply that to auth collection also as an configurable option.