Multiple authenticatable entities and password reset tables

[trail niche]

I have two authenticatable entities: users and customers, and for password resets I'm wondering if I can use the same table for both password_reset_tokens or just use two separate ones.

What would the effort be if I wanted to use the same table for both? Considering that the PK is email and that technically the same email from both a user and customer could be attempted. I'd need an additional column to define which broker or model the email is for.

Otherwise, would it just be simpler to just have two tables to avoid these collisions and any major code updates, despite the schemas being duplicated?

[sinful oxide]

use a polymorphic table for this

[hybrid forum]

You can use a single table for both, but since the primary key is email, you'd need an extra column to distinguish between users and customers. Otherwise, there's a risk of collosions if the same email exists in both entities. That adds some complexity in queeries and validations.

If avoiding collisions and keeping things simple is a priority, having two separate tables is easier. The schemas will be duplicated, but it prevents potential issue and keeps your code straightforward.

So I think sing table is more flexibility but two tables is simpler and safer.

[sinful oxide]

As @hybrid forum mentioned, you can't use the same table without changing it due to collisions. Laravel provides polymorphic relationships https://laravel.com/docs/12.x/eloquent-relationships#polymorphic-relationships, where it enables you to use a table for two different models

Without needing to handle collisions

[trail niche]

Thanks @sinful oxide @hybrid forum

I had a feeling it'd need to be polymorphic. Thing is there is a possibility I'm going to be asked to set up a third user provider at some point and I really don't want to have to keep adding the same table each time. I'm going to do some research into a polymorphic solution.

Just noticed there's a user_id column in the sessions table. I have a feeling I'll need to do something similar for this as well...

[trail niche]

Just finished implementing this and it works a treat 👍 Thanks again

[sinful oxide]

@trail niche how did you implemented it?

[trail niche]

https://gist.github.com/mewtonium/0664c9a3663a4cd6db966d775df10657

In addition to the above:

• Update the password broker to be used in app/Http/Controllers/Auth/NewPasswordController.php and app/Http/Controllers/Auth/PasswordResetLinkController.php, and anywhere else you're using the other brokers. In my case, I set the broker to users in Filament, and customers in the main app.
• The migration is specific to my situation but you'll get the idea. I'd already dropped the original password_reset_tokens table for the two new ones, so I was able to just recreate it with the morph columns.

Looking at it now, it might not have needed to use morph columns and just a single column like broker would be enough. In which case all you'd need to do is change the resettable_* references in MorphDatabaseTokenRepository to broker