Case-insensitive Logins

[SpherAx]

I need to support case-insensitive usernames and emails on the frontend. These fields in the users table can be easily constrained in my PostgreSQL database with unique indexes (see: http://shuber.io/case-insensitive-unique-constraints-in-postgres/). It seems like extendUserQuery() in Manager.php may be the right place to tweak the relevant where clause, possibly by adding one or more ->orWhereRaw() conditions, but I am struggling to make this work. A solution, an example or some advice would be very helpful! Thanks.

[bennothommo]

@SpherAx I would certainly be happy for us to support case-insensitive username/emails across the board, if you were interested in providing a pull request for that.

However, if you just want to do it for your own project, you could create a new plugin, and then as part of the register() method in your plugin, you could overwrite the user.auth singleton bind to point to your own version of the AuthManager.

use Illuminate\Support\Facades\App;

public function register()
{
    App::singleton('user.auth', function () {
        return \Your\Plugin\Classes\AuthManager::instance();
    });
}

You would be correct, in your own implementation of the AuthManager class, you can overwrite/extend the extendUserQuery method to include your additional query conditions to cover the case-insensitivity.

Make sure to make the User plugin a requirement of your custom plugin, so that it loads first, and your user.auth override will apply afterwards.

[SpherAx]

Thanks for the response and suggestions. I have, however, come up with a somewhat easier work-around that meets my immediate needs. In the User plugin's Plugin.php file, I added a boot() function where I registered a listener for the beforeAuthenticate event. My listener requires an external PHP file that validates the submitted credentials via a direct call to a database function. If valid, the listener logs that user in and returns TRUE. Then, in Account.php where the event is raised, a TRUE response simply sets the user with Auth::getUser() and the native Auth::authenticate() method is skipped entirely.

Of course this requires a separate path to the database which, in my case, already exists and is needed for many other things anyway. If I run into trouble, though, and need to pursue the new plugin route, I will post the details and/or submit a pull request.

[bennothommo]

I would caution against making modifications to the User plugin directly, as any changes may be overwritten when upgrading the User plugin to a newer version, but if you're aware of those risks, all good!

[LukeTowers]

@SpherAx be warned, should I ever have to work on that project where you have modified a third party plugin directly I will judge you harshly 😜

In all seriousness though, please do not make modifications to third party code that you do not directly control. It makes future maintenance so much more difficult than it needs to be and with how extensible Winter is there simply is no reason to do so.

[SpherAx]

I hereby acknowledge and confirm that I have been duly warned. For others who may find this thread useful, please note that my solution is clearly, as stated, a work-around to meet immediate needs. Time and experience generally do produce better code. It's precisely when those precious gifts are in short supply that a work-around can save the day.

[LukeTowers]

Fair enough, although we all know just how permanent temporary solutions can become 😂 I have a client with their main WAF in AWS named "temporary-waf" and it's not going to change any time soon 😂 😂 😂