Added case-sensitivity option for usernames

[Radiergummi]

Why
Using Postgres (and possibly other DBMS), comparisons are case-sensitive as opposed to MySQL.
This causes issues where users would enter e.g. Taylor@laravel.com on logging in but registered with taylor@laravel.com, and receive a bad credentials error. This bites every single installation of Fortify using Postgres.

By storing the usernames in lowercase, and converting them before passing it to user-defined authentication logic, this problem just disappears.

Backwards compatibility
I took care to not break BC anywhere:

• The option defaults to true for now, meaning usernames are case-sensitive by default. That way, nothing breaks for existing applications, including those with custom workarounds. It should probably be set to false in the next major revision.
• The case change happens before the input is passed to user-defined actions (e.g. CreateNewUser), so no changes to existing implementations are required.
• The new CanonicalizeUsername action can just be dropped in existing users' pipelines, if desired.

[driesvints]

I'm not 100% sure if a setting is the right solution here but let's see what @taylorotwell says.

[Radiergummi]

I'm not 100% sure if a setting is the right solution here but let's see what @taylorotwell says.

I don't really see another option which doesn't interfere with existing applications, but I'm open for any suggestions!

[taylorotwell]

Made a few changes.

Renamed configuration option to lowercase_usernames. Made default value in fallback config false (to preserve BC), but updated stub value to true so all new applications will get the more correct and expected behavior IMO of lowercasing the username.

[martinbean]

This is an amazing PR, it’s something I have to deal with (and remember to deal with) in applications using Postgres. However, should the lower-casing not be done before storing? Otherwise validations will fail.

For example, say I have [email protected] in my users table. If I try and register with [email protected] then the validation is going to pass because it's different casing. But when the controller comes to actually insert the database record, Fortify is going to down-case the submitted value, and the database is going to throw a unique constraint error (if the column does indeed have a unique constraint).

[driesvints]

@martinbean good question actually. Can you weigh in here @Radiergummi?

[Radiergummi]

In the RegisteredUserController, the given username should be lowercased if the setting is enabled:

public function store(Request $request,
                          CreatesNewUsers $creator): RegisterResponse
{
    if (config('fortify.lowercase_usernames')) {
        $request->merge([
            Fortify::username() => Str::lower($request->{Fortify::username()}),
        ]);
    }

    event(new Registered($user = $creator->create($request->all())));

    $this->guard->login($user);
    return app(RegisterResponse::class);
}

The idea here is to pass the correctly cased value to any user creator implementation already present - that should work well, unless the implementation retrieves the value from the request via any other means or changes the formatting somehow (but I don't think that is very likely).

Have I overlooked something here? Does that error actually crop up?

Edit: @martinbean reading your question again, you were wondering whether the Rule::unique('email') in CreateNewUser could fail if it checks a differently cased variant to the already one stored in the database, right?
This shouldn't be possible as the lowercase value is passed to the implementation, which both validates the input and creates a user from it. So whatever the casing used by the user, we only store lowercase usernames and validate lowercase values against them.

[martinbean]

Sorry, didn’t see there were replies to this.

@Radiergummi, the issue isn’t the persisting of the usernames. Yes, they’re normalised as all-lowercase in the controller. But my issue is, the validation happens before then.

So, if I have [email protected] in my users table. The issue is if someone then tries to sign up but submits the same email address in a different case, i.e. [email protected]. The validation rule is essentially going to do a where email = '[email protected], find no matches, and carry on to the controller, which is then going to lowercase, try and insert the value, and throw a database exception because it’s a duplicate.

[martinbean]

/cc @driesvints

[driesvints]

Maybe we should just add lowercase validation to fortify as well like we did in Breeze? laravel/breeze#321

[Radiergummi]

@martinbean I'm not sure I understand the problem yet; from what I've seen of the Fortify code, validation happens in the CreatesNewUsers implementation, not before -- where would validation take place otherwise in a controller that uses a base Request instance?

[martinbean]

@Radiergummi No normalisation happens in the implementation:

fortify/stubs/CreateNewUser.php

Lines 24 to 30 in b5743b0

	'email' => [
	'required',
	'string',
	'email',
	'max:255',
	Rule::unique(User::class),
	],

So if I try and register using [email protected] then that will pass validation, even if the all-lowercase equivalent ([email protected]) exists in the database.

[Radiergummi]

@martinbean Ah, but we call $request->merge() before passing the request to the CreateNewUser class if lowercase usernames are enabled. This merges the request data in-place, and overrides the given username with its lowercase variant - so the implementation will only ever receive [email protected] in your example.