Laravel: The Power of Authentication [Part 1]

Laravel: The Power of Authentication [Part 1]Forget about using putting obnoxious logic in your controllers.

Learn the REAL way!Italo BaezaBlockedUnblockFollowFollowingApr 29Photo by Fancycrave on UnsplashAs a kind of follow up of my article about how the Authentication works in Laravel, here I will write about the moving parts of the authentication mechanism, like the Authentication middleware, the Guard, the Driver, the User Provider and Authenticatable.

In a nutshell, the Authentication system is basically a Middleware that looks into the Request any resources (cookie, request headers, session, etc) for access credentials (user ID and password, token, etc).

If they’re found, it will pull out the User with those credentials from the application (database, external api, etc) and keep it available during the Request lifetime or subsequent requests.

I humbly recommend you to know, at least, how Sessions and Requests works, and the application lifecycle.

That last paragraph is just the tip of the iceberg.

But the Authentication system is not just a middleware.

It gets very, very complicated once past that.

Luckly, it’s only daunting at first glance, and in the next series of articles, I will uncover how the Authentication system works without bombarding with complicated concepts.

For the time being, picture this:Sublime representation of what the Authentication system is for the uninitiated.

Yep, the tip of the iceberg.

The Authentication middlewareIn reality, there are two middlewares that work for authentication purposes.

The first one is the Authenticate, which represents the main cog in the authentication mechanism, and the AuthenticatedSession middleware which is kinda niche — we will talk about it later.

If you see the middleware priority in your appHttpKernel.

php, you will see the Authenticate is just before the AuthenticatedSession.

If not, then check out the Kernel it extends.

appHttpKernel.

phpThis array defines the order of which middleware goes before another.

This avoids conflict for when a middleware needs what other provides.

Personally I think Laravel could have a middleware property to require others, but for current version this is enough — a lot of middlewares means you’re probably overdoing something.

It starts with AuthenticateWhen you set the auth middleware in your route or controller, the incoming Request will be handled by the Authenticate class.

It receives the AuthManager Service when the application instances it, and this Service returns a Guard by its name.

This middleware will try to check the default authentication mechanism, set in your configuration file, otherwise it will cycle every authentication you have set in the middleware parameters, like in this example:Route::get('private') ->uses('PrivateController@show') ->middleware('auth:token,session,telepathy,hunch,whatever');When it cycles through every Authentication Guard in order, it basically calls the check() method of each guard inside the AuthManager, returning a boolean; the Application will use the first authentication that returns true, and if none says there is an user authenticated in place, it will return an AuthenticationException because there was no authentication capable of tell who is accessing the route.

Illuminate/Auth/Middleware/AuthenticateThe exception will receive the URL where you want to redirect the User if its not authenticated through the redirectTo() method, which receives the Request as a parameter.

You could, for example, redirect the User to a different URL depending on where the Request has been done.

What does AuthenticateSession do, then?This middleware is disabled by default, but enabling it will allow the user to logout from every other device when his password changes.

A quick glimpse on the handle() method tell us that this AuthenticateSession tries to validate the user authenticated by comparing his password hash previously stored in the Session — you will need to use the SessionGuard or similar using Sessions.

So, if the User changes the password hash in the database, all other sessions will be automatically invalidated because these are using the old password hash.

Illuminate/Session/Middleware/AuthenticateSessionIn case you didn’t know, Laravel won’t force the user to be authenticated on only one device.

That means, a user can have multiple sessions opened in different parts of the world, even if the User changes his password.

To tackle that, Laravel allows this middleware to be used in conjunction with the logoutOtherDevices() method, which will invalidate the session in the other devices when the user logs in.

This can be put on your LoginController.

There is a nice video in Laracast that talks about this and how to log out all other devices, so check it out for further details.

If you don’t want, here is the gist: when it receives the password, it rehashes and saves it the database, thus invalidating the other sessions since the hash won’t be equal.

Okay, the middleware is covered, the next step is to understand the Guard Driver and the User Provider.

.

. More details

Leave a Reply