Narrator: We're now able
to make an authenticated request
with this requireAuth middleware,
in which we told passport to authenticate a user
using the jwt strategy
that we defined inside of our passport.js file.
We now need to to create the last route in our application,
the login route.
So to get our login route working,
it's gonna require a little bit of thought on our part.
Right now we've got a flow
where a user can sign up with an email and password
and get a token in exchange.
Remember, as far as a end user is concerned,
as far as, like, you know,
someone who's actually using our app,
they have no idea that a token is involved at all.
So our means of authentication at,
kinda like first glance or, you know,
that first initial contact,
is always gonna be an email and a password.
That means that on our sign in route
we're not gonna be getting a token,
we're going to be getting an email and a password.
So the key here is that we need to find some way
to authenticate a user first with an email and password.
And only when they're able to,
when we're able to confirm that email and password,
then do we give them an actual token.
So here's what we're going to do.
We're going to use another passport strategy.
We're gonna use a local,
what's referred to as a local strategy.
And this local strategy is going to try
to authenticate a user using a email and password.
Local in this case is kind of referring to as,
like local database or data that is stored locally.
So we're going to make another strategy just in line
or kind of like in parallel to our JwtStrategy.
And this local strategy is going to attempt
to authenticate a user given only an email and a password.
If they're successfully authenticated
with email and password,
then we could let them through to some route handler
that will set up, that will give them
a very particular JWT token
that they can then use in the future.
Okay, so let's go ahead and get started.
The first thing we need to do
is install the passport local strategy plugin.
So it is a separate NPM module.
Let's open up our terminal and it closed down my server
and run "npm install -- save passport-local."
And then I'll start my server back up with "npm run dev."
All right, back in our passport.js file
we're going to create local strategy right here.
We need to import our strategy helper.
So we'll say,
"const LocalStrategy = require('passport-local')."
Then we can make our local strategy.
So we'll say "const localLogin" is "new LocalStrategy."
We're going to pass in some options in here
that we'll define in just a second.
And then we'll also have a call back
with an email, password, and done.
So the field in here that's going to determine,
or the kinda the options that we're gonna place in here,
we need to specifically tell this local strategy
exactly where to look in the request
to get access to our email or our kinda username.
So local strategy by default is going to assume
that it's going to be passed a username and a password.
So we're saying, "well, we're not using usernames per se,
we're using emails."
So we need to tell this local strategy right here
to use a usernameField of "email."
This is a really long line.
So let's pull this out to a separate declaration.
I'm gonna say "const localOptions"
is "usernameField: 'email'."
And then we'll change this out to "localOptions."
There we go.
So just to make sure that we're clear on the purpose
of this usernameField right here,
when I sign in, we're going to eventually end up
with something like,
you know, a post request going to probably sign in.
We will not have this authorization header
and I'm going to be posting an email and a password.
So by default, the local strategy is going
to look at the request body
and it's going to find this password field for us.
So the password is handled automatically.
But as far as a username goes,
it expects that it's going to have a username
and it expects that it's going to be available
on the username property of the request.
We're not using usernames though,
we're using email addresses,
and that's why we are passing this option
to say when you want to get access to the username,
look at the email property of the request.
That's all we're doing here.
We're saying specifically, "look at the email property."
So after the LocalStrategy parses the request,
it pulls out the email and the password
and it hands it to us in this callback right here.
So now in here we have to
"Verify this username and password,
call done with the user
if it is the correct username and password
otherwise, call done with false."
Okay, so that's the next step that we're going to do.
Let's tackle this next step in the next section.