All right, and once we have both the error as well as the instant method in place now, let's set up
our login controller.
So I want to go back to our controller.
At the moment, I have no response and I'll leave it because there's going to be some things that I
want to showcase.
And first, let's start by understanding what are we looking for?
Well, if I want to log in, I want to get the email and I want to get the password.
So let's go here with email and password.
Now both of those things are coming from where wreck that body then?
Let's check if one of them is missing.
So I'm going to go, if not email or if not password, and if that's the case, why don't we want to
throw?
Well, let's go with throwing you and by request one correct bad request error.
And we'll just say, please provide all of ours.
All right.
So that's an awesome start.
Then I want to get the user whose email matches of this one want in that body.
How do we do that?
Well, we go user none.
That is equal to await since this returns a promise user, not a man.
We're looking for find and one and inside of the options want to provide the email, which is equal
to my email.
And at this point, essentially I have two options.
If the user exists awesome, we will need to check the password as well.
But if the user doesn't exist, then we want to send back vague, unauthenticated error response.
Now there's multiple approaches to this.
Some people prefer giving a more explicit answer.
For example, there is no user.
We had such email and all that, but I actually prefer the other option where you provide as little
data as possible.
So let's go here.
What if and if there is no user, then let's go through and remember now we have that new unauthenticated
error.
The only thing we need to do here, if you didn't do that already is to go up and just say unauthenticated
error from index jazz.
Let's say this at the moment, I'll have the error.
That's fine.
I just go with unauthenticated and like I said, I'm going to be pretty vague and I'm just going to
say invalid and credentials like, so let's save it now if we have the user.
So if the user exists with such email, what do we want to do next?
Well, we want to compare the password correct with our user compare password method.
How I want to tell you that there is a big gotcha coming up and that has everything to do with the fact
that when we were setting up here, the password, we actually went with select and force.
So let me showcase that first.
I want to go back to controller more specifically logging one.
Let's log the user and then let me showcase the arrow that we're going to go back.
So first, let's go with Konst, and that is password correct?
That's going to be my variable now that is equal to await.
And what is the instance name?
Well, it is user, a man, compare password excel and then we want to pass in the password we have
in the rock that body.
And then let's check what is the value.
So what is the value of?
Is Match A. A. I should be correct, not just as password, and then I'll copy and paste just to speed
this up.
And essentially, the arrow is going to be the same if the password is no match.
The only difference is the fact that and here we're checking for is password correct.
But like I said.
When we will test the south and tell you right away that it will be false, there's actually going to
be error.
Why?
Well, let me showcase that.
So I'm going to navigate back to the postman and I'm looking for to log one and let's set up one from
the scratch.
So I have a logging user.
The route is off logging.
We already did that when we were checking the dummy values.
So now let me go with Jason here, and let's send email now that one will be equal to John at a gmail.com
online.
As far as a password for remember correctly, I set up secret because that's a very secure password.
So let's send it here and check it out.
Now I have illegal arguments, string and undefined, and that is coming from our Beecroft library,
actually.
So in here I can see the all error and all of that is nice.
Now let's go over why we have this error in the first place, and it's very important for me to showcase
the object that we have as far as the user.
So notice our document.
I have daddy, I have the name, email list, name and location.
Now what?
I don't have there.
I don't have the password.
Why this select and enforce?
And now let's keep scrolling and take a look at our company password.
Candidate password, we him that should be good.
What about this sucker?
This is looking for what password, where in the document do we have it?
No, and we kept this like, look, you passed in strength, you passed in on the fun.
What is wrong with you?
What am I supposed to do over here?
So how do we fix that?
Well, remember when we talked about select false.
We also looked at the docks that we can't override that.
If you remember when we were sending a create, I said that it's actually not going to work.
Meaning we will get the password over here in the user.
That's why we were doing all of these acrobatics where I went to an email, email and blah blah blah.
In this case, everything works when we go with find one.
We don't get the password, but this is the case where we actually need it.
Don't you find that ironic?
I do.
And in order to fix that, we need to override when we are setting up or find one.
The way we do that, we go with that and then select.
And now I need to go with Plus and 1Password because by default, it's not going to be provided.
And now everything is going to work.
Now there's another gotcha, but we'll get to in a second.
So let's try it out one more time.
I'll leave all the logs just so we're clear of what's happening.
And then let's go back and then let's send it one more time.
And now everything is correct.
I get back my logging user, and if I take a look at my object right now that everything's correct,
ready are the name and yada yada yada.
So again, select false means that we're not going to get that property in our response in our document.
However, if we want to add it, we go with select and then whatever is the name of the property.
And this is important because user is an instance method.
So there's not password is looking back to this object and saying, get me the password property.
Hopefully that is clear.
And now we simply want to do three things.
We want to set up the token.
We want to send back the response and we want to fix one.
Gotcha that is still working.
So let's go here with token.
VAR is equal to user and then I'm going to go to create an JWT panel was the function.
And now it's set up our response.
And let's see the problem, and then we'll add the fix.
So let's go here with that status and I'm going to go here with status codes and OK.
And as a side note, in between the videos, I fixed the tiny bug I had in the previous and register.
Well, this should be created, that's a proper response when you create the resource on a server.
This is to a one and I went with, OK, my apologies.
So in this case, yeah, I go with 200, but in there we have to go with two.
Oh, one.
And then we go.
Jason and I don't want to do the acrobatics again.
I don't want to go with user and then blah blah blah, because it's kind of annoying.
I'm copying pasting the code.
I'll still use the token on location, but I actually want to serve this user equal to a user.
And of course, the problem is that we have the password, right?
And I said that, well, it's not the best approach doing that way.
So let's just start by user token and location.
It's going to be equal to user and location.
And let me double check that that.
That's definitely a response.
And yes, I see the password over here.
And what can we do now?
Because I do need the password here.
I want to check it and I'll sign up, I think you can remove the user.
But how I can remove it from their sponsor again?
Yes, you can hard code that like we did in the register.
But another way, how we can do that.
I can simply set the password property equal to on the phone.
So I'm going to go here with user password and I'll set it equal to under find.
And as a result, what you'll notice that I get back my user object.
So all of that is correct, but the password is not there.
And if you're wondering, hey, look, but when we were setting up register, there were less properties
and now we have more of them.
Keep in mind that on a front that we look for specific properties.
So the fact that there's an extra I.D. doesn't really affect us as long as we're not sending back sensitive
data like password.
We're actually in good shape and we also have the token as well as the location.
So that's how we can set up our login controller, check for empty values, then check for user, check
for the password, remove the password from the response and send back user token as well as the location.