3.3 Authenticating Users at the Server

Our user authentication is going to be very, very, very familiar, because, well, you will see here in a moment. And we're going to start by seeding our database with some users, so that we have them to work with. So let's go to database > seeds, and we are going to be lazy, and do it inside of the DatabaseSeeder. As opposed to creating our individual seeders for our different models. So let's go ahead and add a use statement for user. And let's be good here, at least, and let's truncate first. And then, we will create our users. So I'm going to create two. The first is going to have the name of Admin and the email address is going to be admin@admin.com, very easy to remember. And if that wasn't easy enough, the password is just going to be the encrypted version of password, very secure there. Let's just copy this and use it as the basis for the next one. In this case, the user will be Joe and the email address will be joe@joe.com. And we'll leave the password as that. So let's run our seeder, php artisan db seed. Hopefully we don't get any errors and it helps if you type that correctly. Always does, so there we go. Let's go ahead and start up our web server so that we can start making requests because that's the next step, well, part of the next step. We're going to go ahead and implement the login view. Now, just as I have done before, I am going to cheat and paste in this markup. And if you look at the markup, you're going to see that it looks very familiar to the log in blade view. And that is because it is the markup from the login blade view. Basically, I took out all this PHP specific stuff, as well as any error reporting and things like that. I just wanted something very simple, so that's basically what it is. There is some view specific things, however, like for the form element, there is the submit.prevent. And then the input elements have v-model set up as well. Now we could come in here and add in the validation with v-validate, like we have done before. However, in this case, once again, I'm going to be lazy and just rely upon the browser to do it. Because Chrome supports the email type fields, and required and all of that stuff. So we can just dive on into our JavaScript. So we have two pieces of information, we have the email and the password, so let's go ahead and define those. I will initialize them as empty strings because we don't have any data to work with right now. And, yeah, that needs to be return there. And then we will write our method. Now our method isn't going to be really anything spectacular. We are going to make a request to our login route. That is, how we are going to log in. So the very first thing, we'll use axios. We'll post and that will go to /login. We will pass in the email, and we will get that value and the password, and that value as well. And this is how it's going to work, whenever we successfully log in, we get redirected. So if the then method is going to be called, then we have something along the lines of okay. It's not specifically okay, but the response is not an error, I should say. So in that case, we are logged in. So we will use the router to take us to our home page. And that is simply /. So there we go. Now if we get an error as a response, then the authentication failed. So we just need to display a message to the user that says that the email or the password is incorrect. We could be a little bit nicer there, like it doesn't match our records or something like that, but this is going to be fine. So that's how this is going to work. And let's go ahead and import axios as well. Now there is an issue. Because right now all of our routes are set up using what was given to us by the off scaffolding. So if we go and look at our routes, we will see that we are using that off routes. Now, normally this wouldn't be an issue but let's also think about our current implementation. Only authenticated users have access to the admin section. So if we just use auth routes, that means that the register route is, well, registered and somebody could make a request to that route and create their own user. That is a huge security hole. Now, let me once again stress that in a real world application, everybody would have to log in in order to do what they wanted to do. Normal users would have to log in to submit a ticket and check on the status. And then for the support staff, they would have to log in. But we would have user management, different roles, different groups and all that stuff. But since we made our bed, we have to lie in it. So we are going to not use auth routes here. Instead, we are going to define two routes. The first is going to be for our login, so this is going to be a post request. And then we will specify Auth\LoginController, and the login method. Now, because we have the login, we also need to specify the logout. In fact, we will get an error if we try to do that. But we also need to give this a name because our application is expecting a route with a name of logout. So we will go ahead and specify that, as well. But once that is done, we are ready to go. So let's go to the browser, and we have our login form. Let's pull up the console, so that we can see the data going back and forth. So let's try to login with something that does not exist. So we will login, we get a 422, which that is expected and we see that the email address or password is incorrect. Of course, yes. So now let's try to login with a real user. So admin@admin.com, the password is password. And we make our request. But it doesn't take us to our dashboard. Well, let's look at the requests that were made. Of course, this first one we can ignore. So we make a request to login. It redirects us, so that's good. And then, there is this request to profile. Because we were attempting to navigate to our dashboard, what we implemented in the previous lesson, the profile is going to be checked before we get to the dashboard. Now, if we look at the profile, we have null. And so because we have null, our application is thinking that we're not logged in. So our application is doing what it is supposed to do, at least as far as the client side is concerned. What we need to do then is make sure that whenever we access anything on our API, that it knows that we are logged in as well. And this is where Passport is going to come into play. Passport is a fantastic solution for providing authentication for web APIs. And so what we want to do is install that and add it to our application. Because not only can you use Passport for authentication for any type of client like a mobile device or a desktop application or even another website, but we can use it for our JavaScript application as well. So we want to composer require laravel/passport. And while that is going, we are going to go to config and app.php. So there's a lot of files that we have to touch here. And we want to add to the providers array the PasswordServiceProvider. That is in Laravel\Passport\PassportServiceProvider class. Now, after Composer has given us passports, we have some migrations that we need to run. So we'll say php artisan migrate, we'll run those migrations. And then we need to install it, so with that, we we use passport:install. And while that is installing, we will go back to our code because we need to go to the user file. We need to add a use statement for Laravel\Passport, and then HasApiTokens. And then we have a use statement. Well, we have a use statement, we're going to add to the use statement inside of the class the HasApiTokens. Now, from here we are going to go to app > providers and then the AppServiceProvider. We're going to add a use statement for Passport and that is in Laravel\Passport\Passport. And while we don't really necessarily need to do this now, we're going to go ahead and do it anyway, just so that if we do need it in the future, it's already done. And that is to simply call Passport routes inside of a boot method. Now from here, we need to configure the off and we went go down to guards for the API. The driver is not token anymore, it's going to be passport. And then we went to go to kernel.php that is inside of the Http folder. So kernel Http and to our web middleware. We are going to add, and this is really the magic thing that's going to work for us is the CreateFreshApiToken. That is in Laravel\Passport\ Http\Middleware and then CreateFreshApiToken. What this is going to do is it's going to give us a cookie that will have the token. So that our requests are going to automatically include that token, we don't have to do anything and everything is just going to work. And so now the final thing that we need to do is modify our API route. So let's go to our API and we are going to specify that we want to use the middleware for our profile. So we will say middleware, and auth api and then get. Okay, so now let's go back to the browser and let's refresh. And you know what, while I'm thinking about it, we can go to our admin.js. And let's look at this, if we are making a request to profile and if we are logged in, then we don't really need to test to see if we have any data. If we are logged in and we don't get an error with the response, then everything is fine, we're logged in. So we'll just say next. Otherwise, we will go back to the login page. So we do need to fire up our servers. So php artisan serve. And there we go. So let's refresh the page and let's see what we get here. So let's try to log in with admin@admin.com, password. And what happens? We are redirected to the dashboard. If we look at the profile, we can see that we are getting our information. So if we wanted to, we could use that somewhere within our view. But for right now, I'm just happy that this worked. And so in the next lesson, we will display something in the dashboard, probably just our list of tickets.