#Registration doesn't convert emails to lowercase allowing duplicate accounts

27 messages · Page 1 of 1 (latest)

gilded quiver
#

I've a Filament Panel configured with ->registration and it seems that it's possible to create duplicate accounts by entering the same email in a different uppercase/lowercase combination.

For example:
[email protected] Works
[email protected] Also Works
[email protected] Also Works

Source code reference: https://github.com/filamentphp/filament/blob/4.x/packages/panels/src/Auth/Pages/Register.php#L184
The getEmailFormComponent does have the ->unique configuration set but that doesn't take effect when the case is changed

There are a few possible ways to resolve this

  1. Add an Eloquent mutator to the User model to convert emails to lowercase before creating the record. (In this case the DB unique constraint would catch the duplicate account)
  2. Change Filament to Mutate Form Data before saving, This would require an update to Filament or an internal patch modify the registration page

Please let me know if there are any other ways to resolve this that I'm not aware of.

GitHub

A powerful open source UI framework for Laravel • Build and ship admin panels & apps fast with Livewire - filamentphp/filament

#

btw, Any changes to Filament would also need to update Login ( https://github.com/filamentphp/filament/blob/4.x/packages/panels/src/Auth/Pages/Login.php ) to convert the emails to lowercase before attempting to login because as of now you can change the case-sensivity and login to other variations of the same account

GitHub

A powerful open source UI framework for Laravel • Build and ship admin panels & apps fast with Livewire - filamentphp/filament

young pivot
#

@gilded quiver are you using Postgres

gilded quiver
young pivot
#

because we generally aim for filament to have behaviour consistent with the starter kits

gilded quiver
#

Seems like their registration page converts the email to lowercase before creating the account

young pivot
#

if you show me the line where it does that, i will do the same

gilded quiver
#

This is how it appears on the profile page

gilded quiver
#

I'd be glad to make this change to Filament if someone can help me with the process

#

I'm not familiar with the process of contributing to an open source project

gilded quiver
#

@young pivot Out of curiosity, If the aim is for filament to have behaviour consistent with the starter kits, shouldn't we also use Forify for handling authentication?

gilded quiver
#

Setting a mutator for setting the value prevents the account from being created by throwing Illuminate\Database\UniqueConstraintViolationException

#

And the ->unique() configuration on the TextInput seems to be the only way uniqueness is validated

#

Is there a way to configure Validation in such a way that SQL errors bubbles up to the validation?

young pivot
#

I don't want to use normal Blade views etc for auth, we have Livewire components that can be changed using Filament principles, which is why we don't need Fortify

#

But I am happy to copy the behaviour

#

If you don't want to do a PR thats ok, but please add it to my todo list by creating an issue with a simple reproduction repository (just install a panel with registration)

gilded quiver
#

No actually I'd be glad to do a PR for this because I need to fix the issue for myself anyways

gilded quiver
#

@young pivot How would you suggest I approach fixing this?

  1. Convert the email to lowercase using Str::lower in the handleRegistration function before creating the record ( https://github.com/filamentphp/filament/blob/4.x/packages/panels/src/Auth/Pages/Register.php#L126 )
  2. Register a mutateFormDataBeforeCreate but I'm not sure if it will work on the Registration page because it inherits from SimplePage
  3. Change the state directly on the email TextInput using afterStateUpdated()
GitHub

A powerful open source UI framework for Laravel • Build and ship admin panels & apps fast with Livewire - filamentphp/filament

young pivot
#

probably dehydrateStateUsing() on the email field, but i think we need to consider consequences too for the login process, and its best if you just open an issue so we can discuss it more officially