Instructor: In the last section,
we were setting up our local strategy
for helping users log into our application.
I wanna take a second and just make sure
that it's crystal clear
why we're building this local strategy
when we already have a JwtStrategy down here.
Let's take a look at a diagram
that illustrates our different authentication flows.
So right now, we've kind of got really three use cases.
We have the case in which a user is signing up,
signing in, or making an authenticated request.
When a user is first signing up,
they are going to send us an email and a password.
We're just gonna verify that that email
is not in use and then we're going to
return to them a token.
In other words, we now consider them to be authenticated.
In the case that a user is trying to sign in,
we're assuming that they're going to send us their email
and password.
We're gonna verify that the email and password are correct
using our local strategy.
That's what we're building right now.
And then, we'll give them a token.
So we then consider them to be authenticated or logged in.
Then, in the future,
when a user wants to make an authenticated request,
we will verify the token
so we're gonna assume
that they're gonna send the token along.
We'll verify the token and give them access
to whatever the given resource is
that they're requesting.
So the key here is that this verified token
is using the JWT strategy that we already created
but verifying an email and password
is going to be using the local strategy
that we're working on right now.
I just wanna make sure that that was clear,
why we have two strategies.
Okay, so looking at our strategy again,
we need to verify that this username,
excuse me, verify this email and password are correct.
And then, we're going to find the user
and call this done callback with that particular user.
And I put username in here twice
but I really mean email.
Okay.
So we need to somehow figure, find this user
and then compare the passwords.
So we need to find our existing record
in the database for this email
and then compare the password to this password right here
that the request is supplying to us.
To find the existing user in our database
with this email, we'll use our user model,
which we already required at the top,
and we'll find an existing user
who already has this email address, okay?
So we're assuming that if someone is trying
to log in with an email,
we're assuming that it's gonna already exist in our database
so we'll search the database,
try to find this email in there already.
Then, we'll put our callback in.
Remember, doing a search is asynchronous
so we need to supply a callback.
And it's gonna be called with an err object
and our user.
So first, if there is an error in the search,
we'll just return early with an error object.
And then, we need to handle the case
if a user was not found,
so if a user thinks they have an account
but they really don't.
In this case, we'll return done.
There was not an error, per se,
so we're not gonna return an error object in this case,
but we are gonna say false.
So user was not found.
So now, we need to put in our logic
that says compare passwords basically.
This is where we're gonna compare our passwords.
Is password, and I'm using password in reference
to this password that was supplied by the request,
equal to user.password?
Okay?
So this is the question we now need to answer.
But if you recall,
when we store our user,
we hashed and salted the password.
Remember, we've got this really long password on here
so we can't just do a plain string comparison.
We need to somehow decode this stored, encrypted password
and compare it to the password that was supplied
with our request,
which is going to be a plain text password.
So we need some ability to compare an encrypted password
to a normal password.
Let's continue with that in the next section
because it's gonna be a fun one.
It's gonna wrap up all the talk that we had about bcrypt.
So let's do this comparison in the next section.