-: We've now got a middleware in place
to keep users out of this sign-in route
if they have not supplied the correct username and password
or email and password.
As a reminder, that's happening because we've supplied
a required sign-in middleware
to our post to a sign in route.
So, before our user's ever gonna see authentication.signin,
they're gonna run through our
local strategy middleware right here.
And if they did not supply the correct email and password,
boom, they get knocked out of the flow.
So, the last thing we have to do in here,
our user has already supplied and had verified
their email and password,
we just need to give them a token.
So, remember we already created
a token for user helper up here,
but the catch was that we had to supply an actual user
because the token is going to wrap the user's ID.
So, we need to somehow get access to the current user's
current user model, there we go.
Current user model inside of this function.
Luckily, passport has our back.
If you recall in our passport file,
when we set up our local strategy,
this done callback that we called at the very end
when we said yes, the two user,
you know, correct email, correct password,
everything's good, we found the user model
and we supplied it to this done callback right here.
So, this done call back is supplied by passport
and passport, very helpfully
takes this user model right here
and it assigns it to req.user or request.user,
that means in our authentication controller.
In here, we can make reference to req.user
and that is our user object.
So, now, we can just use our token for user helper
and return a token back to whoever tried to sign in.
So, we will say,
response.send
token
token for user
req.user, like so.
All right. Let's go ahead and test this out inside a postman
and see if everything's working.
I'm going to go ahead and create a completely fresh user.
So I'm gonna,
I've got a post, I'm gonna go to sign up
and I'm going to have a completely fresh email here
of email 09, just needs to be something unique.
So, I'll sign up, I get my token, so that's good.
You know, my signup is still working.
This is the handling the case
in which a user is first signing up.
But I wanna handle the case in which I am signing in.
So, I'm gonna change my route up here to sign in.
I'm gonna leave my email and password here
'cause I have to supply email and password
in order to attempt to sign in.
I'll send.
And I successfully get back a token.
Perfect. Just what we wanted.
So, this token means
yes, you supplied the correct email and password
for this existing account.
We verify that it has the correct email,
we verified it as the correct password,
and in return we give you a token
that corresponds to this user account right here.
If I try giving the wrong password right now,
so, let's say, I do a password abcd
and I send again,
I get an error of unauthorized.
So, I'm not allowed to get access to this route.
Let's go back to the correct password.
What was it? 123.
And I'm back to getting my token again.
Just what we wanted.
So this is fantastic. This looks very good.
We've got our token, we've got our sign in,
we've got our sign up,
and we've also got a protected route.
Remember, our protected route was the root route
of just local host 3090.
And then we took our token
and we added it as an authorization header in here.
So, if we send a get request,
we get "hi there" back.
If we do not supply our token,
so, if I click this little checkbox here,
"unauthorized".
We need to supply a token
in order to get access to this content.
So, this is awesome.
This is our server in total.
We've got our different routes put together.
Let's go ahead and do a wrap up of our server
in the next section.