Laravel 5.2’s Authentication

I recently started using Laravel 5 (after having written a fair amount in Laravel 4) and was excited to find authentication built into Laravel 5. Well, you do have to execute “artisan make:auth” after you create your project, but after that it just works.

Laravel’s built in authentication has some advantages:

1) Login throttling is done for you. This is an important part of making brute force and dictionary attacks on your login form impractical. If the user can only try logging in every so often, then it takes a lot more time to try the tens of thousands of possible passwords a dictionary attack might use.

2) It provides a Remember Me feature for logins

3) A sample layout is provided for you that toggles a top navigation bar between Login and Logout, showing you the technique to use.

Unfortunately, there are also some disadvantages:

1) A relatively minor one, the layout that is generated using URLs for form actions and links, rather than using named routes or the action helper. Putting URLs into views makes reorganizing the site structure later more difficult than if routes.php is the only place where URLs are found.

2) The built-in authentication does not generate events, which makes it difficult and non-standard to try to hook into the login and registration process to tweak how it works.

3) There’s no support for sending confirmation emails during the registration process, which means you have to deal with the issues brought up by #2.

There is some support for extending the AuthController class. You get generated automatically validate and create methods that you can modify if you add fields to the User model.

There is also an undocumented hook method named authenticated ($request, $user) that is called by Laravel’s built in authentication after the user has been logged in. This can be used to send a confirmation email and otherwise enforce whether an unconfirmed user may actually log in.

Unfortunately that hook method is not called when the built-in authentication logs a user in after registration. That sort of inconsistency hampers customization efforts that don’t involve wholesale copying and pasting of code.

Other sorts of customizations are more difficult. For example, to allow a user to log in with either a user id or email requires overriding the login method and copying some of the code from the AuthenticatesUsers trait.

Ultimately, no built-in authentication can do everything that every site needs it to do, so Laravel’s built-in authentication needs to be easier to extend and customize. Using Laravel’s own built in event system would be a good start.

This entry was posted in Laravel. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *