Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.3 Write a Custom Guard

Guards authenticate users for every request. For example, Laravel’s built-in SessionGuard uses cookies and session storage in order to ensure the user is authenticated. We’ll keep it simple, but you will learn about the Guard interface and you’ll get to write a custom guard.

Related Links

2.3 Write a Custom Guard

If you'll remember from a few lessons ago I mentioned that Laravel's user authentication is made up of two pieces. First, we have the provider which you know is responsible for working with and returning users from our data store. And then we have the guard which is responsible for ensuring that the user is authenticated for every request. And in the same vein of the previous two lessons we are going to create a very simple guard, but in this case it's going to ensure that everybody is logged in all of the time. So we should never see the login form by the end of this lesson. It's just going to automatically log us in and that's going to be it. So it's definitely not something that you would want to use for a real application. So there is an interface, an Illuminate\Contracts\Auth called Guard. And this is the interface that we need to implement if we want to write our own custom guard. So I'm going to copy all of this and we will talk about it as we write our code. So let's go to our extensions folder. We want to create a new file and I'm going to call it MyGuard.php. And we want to set the namespace to App\Extensions. And let's go ahead and define that class. So MyGuard implements Guard and then we're going to paste that in. Now there's a few other things that we need to use here. The first is going to be our MyUsers, so that is in Extensions and then MyUser. But then we also want to reference the Guard interface, so you use Illuminate\contracts\Auth\Guard. But we also need the authenticatable interface as well, so we will bring that in. But we also need something called a guard helper and this is inside of Illuminate\Auth\GuardHelpers. This is a trait that we are going to go ahead and add a use statement for. So use GuardHelpers and that's all that we need to do there. So the first method that we need to implement is called check. And you can see that it determines if the current user is authenticated. So our guard is going to always a log-in a user. So, in this case, we want to return true. Now of course, if this was a real guard we would do whatever it is that we needed to do in order to check if the user is authenticated. So if we were working with sessions, then we would be checking the session storage for our user information and ensure that that user is logged in. The next method is called guest and it determines if the current user is a guest. So once again if this was a real guard, we would do whatever we needed to do to check to see if the user is a guest. In this case we're going to return false because we always want to be logged in. Now, the next method is called user and it returns the currently authenticated user. Now, in our case, we don't have a data store to check anything against. We don't have any storage or session storage that we stored our user. So we are just going to create a new user and return that and we did that in the previous lesson inside of the user provider. So let's copy that code that creates that new user object and we will use that for the body of my guard, except that in this case let's change the name. Instead of static user, let's say do not use user. That way, whenever we test our application again we should see the name do not use user. And that way we know that our application is using this completely useless guard. The next method is called id and we want to return the ID for the currently authenticated user. Now, see that it returns int or null. So, if a user's not logged in, then it would be null, otherwise is going to be the value of the user's ID. Since we've hard coded everything we're just going to hard code this as well. So the value is one. And then the next method is called validate where it validates the user's credentials. Now, in this case we're just going to return true. But once again, in a real guard we would want to actually validate those credentials. And then finally we want to set the current user. Now, we don't need to do that because for every request we are going to create a new user. So in this case we are simply going to well, we don't need to do anything. There is no return value so this method is just going to execute and not do anything. So that is going to be our very simple guard. The next thing we need to do is register it and we do it in almost the same exact way that we've registered our custom user provider. So let's go to the AuthServiceProvider, inside of the Providers folder. And we're going to use the Auth facade. But here we aren't going to call the provider method, instead we're going to call extend. And the arguments are going to be the same that we pass to the Provider method. The first is the name that we want to give this guard. So let's call this do not to use guard per, well, it's not a provider this is going to be called a driver. So let's say donotuse-guard-driver. The second argument is a closure that contains information that we might need in order to create our guard. So the first is the app, second is the name, and then third is the configuration. So config. But once again, we aren't going to be using any of that. We are simply going to return MyNewGuard. And that's going to be it, although we do need to go to the top here. And we need to say that we want to use App\Extensions\MyGuard. Now the final step is going to our Auth Configuration and then changing the driver for our web guard. So you can see that right now it is set to session which makes total sense. And we're going to change it to something that makes absolutely no sense. So the driver is going to be set to the name that we used whenever we registered our new guard driver. So let's copy that value. Let's go back to auth.php and paste that in. And there we go. So if everything was done correctly we should be able to go to the browser. Let's refresh the page to see if we get any errors, we don't. Now if we go to log in it should automatically log us in and take us to the home page. Or if we just go to slash home, then that should also log us in and it does. We are now taken to the dashboard, we are logged in and if we look at the name of our user it is do not use user. So this is the user from our guard. So our guard is working. Or not working depending upon how you want to look at it. So as far as the concept is concerned, writing a guard is very simple. There's just an interface that you need to implement. You need to pull in those guard helpers, and that's the easy stuff. From there, the real difficulty comes in to writing the code that your application needs.

Back to the top