7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.3 Authenticate our Admin Users

In order to authenticate our admin users, we need to write a controller to log them in. We'll do just that in this lesson.

3.3 Authenticate our Admin Users

In the previous lesson, we created an Admin Guard. So that we could use that to authenticate our web application's administrators. However, we ran into a slight little problem. Whenever we logged in, we did so using the default Web Guard. And so whenever we tried to access something that was protected with the Admin Guard. Well, it didn't work, because we did not originally authenticate with the Admin Guard. So what we need is another login form. We need a controller that we can use to log in our admins. So that then they can have access to the admin portion of our application. So we're going to start by creating a new controller. So let's go to app > Http > Controllers. And inside of Controllers, we're going to create an Admin folder. Now we already have a controller for authenticating users. It is inside of the Auth folder and it's called the LoginController. So let's just copy that and we will paste it into the Admin folder. And we will, of course, need to make some modifications. The first is going to be the namespace. This is no longer the Auth namespace, this is going to be the Admin namespace. And we also need to bring in the auth facade. So let's do use Illuminate\Support\Facades\Auth. The reason why we need the auth facade here is because we are going to tell this Controller that we want to use the Admin Guard. And we do so very easily by just writing a method called guard. This is going to be protected function guard. And this is simply going to return the result of calling the guard method auth facade. Except here, we are going to specify that we want to use the Admin Guard. So now, this LoginController for our admins is going to use our Admin Guard. Now there's one other thing that we need to do inside of this class. But first, let's go ahead and create the view. And we're going to do the same thing that we did with the Controller. We're going to go to the auth folder and we're going to copy the login view. So let's go ahead and copy that. Let's create an admin folder. We are going to paste in that view and we're going to make a quick little modification here. We're going to say that this is the Admin Login. Just so that whenever we are seeing this in the browser, we know that we are at the Admin Login. We also need to change the URL for the action. We don't want to go to /login, instead we're going to set up a route that's going to go to admin/login. And that's all that we need to do here. Okay, so for our LoginController, it's using this AuthenticatesUsers trait. And there's a method there called showLoginForm. What we need to do is write that method here. So that we override the method from that trait and tell it that we want to use our admin view. So we will say showLoginForm and this is simply going to return the view of admin.login. And now we just need to define our routes. So let's go down to the routes folder. Let's open up web.php and we're going to leave our existing Route for admin alone. And instead here, we're going to define a group and the prefix is going to be admin. And then inside of our closure, we're going to define three routes, two for the log in and then one for logging out, so that we can log out. So let's first do the get request for logging in. So the path is going to be login and we want that to go to Admin\LoginController@showLoginForm method. Now, let's go ahead and let's name this and we will call it admin.login. And the other Route for the post request is going to look very similar. The path is login, the controller is LoginController. But in this case, we're going to go to the login method and let's change the name of this route to postlogin and we need one for logging out as well. So let's change the path to logout and the method is logout and we don't need anything else here. Now, I just wanted to point out that I'm using a get request for logout. The reason being because we don't have a button or anything that we're going to click on that's going to take us to the logout with a post request. Normally, you would use a post request. But in this case, we're just going to type logout in the address bar and that's going to log us out. So let's go to the browser and let's try this out. So if we attempt to log in with a normal user or any user for that matter using our normal login, we're still going to end up with the same results that we saw in the previous lesson. We will not have access to the admin portion of our application. So let's go to admin and then let's go to login. And we will see our Admin Login form. So let's log in with our admin and then we should have access to our admin controller. And well, we were redirected back to the Login form and this is what happened. Okay, so we logged in and it redirected us back to home. And because we aren't authenticated using the Web Guard, it then redirected us back to the Login form. Now we can control where we get redirected to inside of our controller. There's this property called redirectTo. And if we change this to admin, then whenever we log in it's going to redirect us back to admin. So let's see that in action. Let's go to admin/logout and then we will go to admin/login. We will log in again. So admin@admin.com, password. And there we go, we have access to our admin controller. Finally, but as we just demonstrated, we don't have access to home. Because home is being protected by a different guard, we are not authenticated there. So now you might be asking yourself why use multiple guards like this, especially since it seems to require you to write more code. Well, let's think of it like this. We have a very simple application but it's divided into two parts. We have the front end and the back end and there are a lot of applications like that. But typically, you have your authentication system and then you have your authorization system. So you would define roles that you would then apply to users. And then you would check for those roles in order to determine whether or not they get to see what it is that role allows them to see. Now that's been done. However, with a guard, all you really need to do is define how you're going to provide users for that guard. So in our case, we modified our users table, gave it an admin flag and then wrote a provider to supply those admin users, but you wouldn't even have to do that. If you wanted to define a whole new table for just admin users, you could do that. So that you could completely separate your regular users from your admin users. Now of course, there comes a point where you have to decide is it best to use an authorization system or is it best to use a guard. Because if you end up with an application that requires a lot of extra roles, then an authorization system might be better. Regardless, it's another tool that you can add to your bag of tricks that you can use whenever it's appropriate to do so.

Back to the top