5 => User Accounts & Authentication

Implementing Authentication In Laravel

This entry to the blog will explain how I personally went about adding authentication into an existing application along with the issues I faced. I'll be covering both the good and bad, what I found intuitive and where I feel that Laravel could potentially improve and why.

Database Table Structure

So far the project already has a users table that were generated by default. This table is already suitable providing the appliation what it requires for authentication, the application just needs the logic for authentication. Each users table has the following general structure :

The following is an example of some data that has been generated with Faker through the use of Factories( you can read more about factories in blog #6 ). You'll notice that every password is identical, at the moment as they are hardcoded. The pre-hashed version of the password is the word 'password' so that while testing functionality I don't need to remember 5 different passwords

 

Laravel conveniently provides the suitable database migrations to create appropriate table structures for implementing user accounts whenever a new project is created by default as most applications. 

Laravel/ui

The official Laracasts series named Laravel From Scratch walks viewers through the process of creating login screens using a composer library that creates boilerplate pages and routes for authentication called laravel/ui. To install this package the following command must be run in the root directory of the application.

This command installs the package as a dev dependency (the --dev flag does this).

Once installed developers can automatically generate these views and routes by using the following command.

Different types of views can be generated, for example if the project is using React or Vue then views for these frameworks can be generated as well. The package is flexible. Running this command generates several views that handle authentication logic, as well as generating authentication routes in the routes.php file and controllers for handling the authentication logic.

The following routes were also generated by the command.

If you are in a position in which you would like to modify these routes they are located in app_route / vendor / laravel / ui / src / AuthRouteMethods.php # auth()

Middleware

There are different ways to secure routes and the actions that a controller can take. For this application I secured my controllers actions by adding the auth middleware to the controller in the controllers constructor. 

Clients that wish to use this controllers actions via the applications routes are now required to be authenticated. If they lack valid authentication the controller will return an error response code while preventing them from leveraging any of the logic contained within its methods. In order for the controller to determine whether or not the user is authenticated a CSRF token must be passed to the controller in a header or a cookie. The following is a dumpdie ( dd() ) of an incoming request to the BoardsController (many of the lines are omitted here to highlight the relevant information). Adding a CSRF token to a requests headers is covered in a later blog post that you can read here about AJAX requests.

If a user is authenticated then the users information, like their ID and username, can be gathered by using the Auth::user()

Concluding Remarks

Rapid implementation of basic authentication heavily relies on the generation of scaffolding code. If you are in a situation where you would like to add this functionality to a codebase you have already written using Artisan then you're going to run into some styling problems however these can be fixed easily although it could potentially take some time for you. Initially the way Laravel handles authentication is a little unclear as the majority of its implementation isn't something you interact with however the more you work with it the more clear it becomes.

Laravel is great at abstracting things away from the user and hiding implementation details from you that you don't need to know, which is great, until you want to know how something works. Up until now I never felt as though this was an issue however when it comes to authentication simply trusting the application can do its job feels strange as you have had minimal say in how it was configured. This is most certainly not always the case, if your application is more complex it may require an authentication system to be built from the ground up ( the documentation does explain how to do this ) however for this project that was unnecessary. 

If you are required to debug something relating to authentication things can get difficult rather quickly. If you want to know how Laravel is doing something then you're going to have to read through a significant amount of source code or documentation which can be costly when you're limited on time.