Narrator: In the last section
we implemented our compare password functionality,
which made use of bcryt to compare our stored password
and our candidate password.
Let's go back and finish up our local strategy now.
So we're at the point here
where we can compare our password.
We can compare is the password that was supplied
by the request equal to our saved password.
So to do so, we can say user,
user here is the user that we found in our database
with a corresponding email.
User dot compare password.
Password, this is the password from the request.
And then we'll pass our callback in here
and it's gonna have arguments, err and isMatch.
So if there was an err,
we're going to return early
and we're gonna call done with this err.
If it is not a match,
so if not isMatch return,
done.
And there was not a err in this case,
so we'll pass in null, but we are going to say false.
We did not find a user.
Otherwise return,
done,
null,
with user.
And that's pretty much it.
So this is going to find an existing user in the database.
It's gonna compare the password that was supplied
by the request with the user's saved password.
If they are the same,
it's gonna call the passport callback with the user model.
Otherwise it calls it with false,
meaning, no, we didn't find a user, sorry
but you know, didn't match up.
All right, so recall that these locals
or these strategies that we're creating right here
we have to actually tell Passport to make use
of these strategies.
So down at the bottom of this file,
well really quick, we created the local strategy
and then we saved it as local login right here.
So down at the bottom of our file
we need to tell Passport to use this strategy.
So we'll say passport dot use local login.
All right, so this is really now ready
for a little bit of use inside of our router.
So here's what we're gonna do.
Let's go back over to our router
and we're going to say
that we're going to add another route,
a post request to sign in.
Okay?
Now, before a user goes here,
which is, you know,
this is gonna sit inside of our authentication controller.
We want them to, we wanna verify first
that before they go to this essentially protected route,
we wanna verify that they supplied the correct username
and password using the strategy that we just created.
So we will create another helper like this requireAuth.
That's basically put in
to intercept the request ahead of time.
So we'll make another helper.
We'll say const
require sign in,
passport dot authenticate,
this time with local.
And again, we don't want a session.
So now before a user can go
to the sign in route handler,
we're going to require
sign in.
Okay?
So this is kind of a interesting approach we've taken here.
We've put this require sign in into a middleware.
So it's going to attempt to authenticate the user
before they hit this route handler.
Let's go ahead and create the route handler
and then we will probably take a break
and continue in the next section.
So inside of our authentication controller
we'll create a new helper.
So exports sign in.
So we have function with request, response, and next.
Okay, so in here, at this point in time
user has already had their email and password auth'd.
We just need to give them
a token.
Token.
There we go.
All right, so let's save this
and let's wrap this up in the next section.