We have now spent a very long time around sign up but we are all done really for real this time.
So now going to start to move on to our next root handler.
And believe me everything else inside of this service is going to go forward.
Much much more quickly.
We've really covered all the really big topics we need to be aware of and we get to breeze through everything
else inside of here.
So in this video we're going to start to put together our sign in roots so our ReACT application or
right now postman is going to make a request to sign into our application when they do so they're going
to supply an email and password and then we're going to go through the following series of steps we're
going to first take a look into our Mongo DB database and see if a user with this email exists.
If the email that was supplied and said the request doesn't exist or is not tied to an user inside of
our database then it must be an invalid log in request.
So we will respond with an error immediately if that is the case.
Now assuming that we do find a user we're going to compare the passwords of the stored user and the
supplied password present inside that request.
And remember we already put together a method to inside that password service thing or that password
service class to handle password comparison if the two passwords are identical then Hey fantastic.
We'll now consider this user to be logged in so that we are going to send them a Jason web token in
that cookie using the same kind of strategy as what we did back inside of sign up over here.
OK.
So with all that mind let's get to it.
I'm gonna flip on over to my sign and to file.
We've already got a little bit of code inside of your already.
So we'll go ahead and start to augment this the person we're going to do is do some validation on the
incoming request so I'm going to add in an import statement or body from Express validator.
Remember this is a method that can be used as a middleware to validate incoming data on the body of
this post request.
So I'm gonna put an array inside of here that's to organize these different validation functions.
We're going to do some very similar validation to what we did back inside a sign up so let's do a check
for email we'll make sure that it looks like an email and we'll put in a custom message if something
is wrong with it so we'll say email must be valid then as a second entry inside this array so note the
comma over here we will put in body we're gonna check the password this time we'll go ahead and do that
sanitization step of trimming it to remove any spaces on the left or the right hand side of the supplied
password in this case we do not need to check to see if the length is valid because our validation rules
or exactly what a password is might change over time it might be that at some point in the past we allowed
passwords all the way up to 30 characters whereas now the limit or the maximum is 20 if we just arbitrarily
put on some validation step on the password right here that would lock out any existing users who do
not or who have passwords that don't follow these rules.
So we will however require that a password is supplied so to check for that we're going gonna put in
a check right here we're gonna look for is or is it not empty like so.
So if the password that is supplied is an empty string.
This is going to throw in their will then put on a custom message.
Once again we'll say something like you must apply a password that will work gets that looks good to
now we'll go down into our actual body down here going to delete that resort send for now you'll notice
that we are getting an air around rec and rest now.
That's because typescript is no longer doing some type in inference for us which it was able to do when
we only had two arguments being passed into post.
So just as we did before back inside of sign up we have to import these types of requests and response
from Express at the very top and then use those types to annotate these arguments the request and response
then inside of here once again just like we did back inside of sign up.
We need to take a look and see if anything went wrong during that validation attempt.
So we essentially need to duplicate the exact same logic that we've got over inside of our sign up request
handler right here.
It's kind of unfortunate to have to duplicate the stuff directly over.
So as you imagine this might be a good location or a good time to try to figure out how to make this
error checking code a little bit more reusable.
But right now let's just rewrite the same thing.
So I'm going to check to see if there are any errors by doing a validation result on the incoming request
validation result is a function that is coming from that express validator library up here so right
after body we're gonna make sure we also import validation results that's going to give us back any
errors on that request.
Well then check to see if it is empty.
So this thing is not empty
then something's wrong.
We should throw in air and remember we put together an error specifically for this purpose instead of
our ears directory.
There is that error we had put together of request validation error.
So let's re import that into this file and we get through it from right here at the top and going to
imports request validation error from up one directory errors request validation error
then back down here.
OK if the errors is not empty row new request validation error and remember the requirement here is
we pass in the array of errors we'll pass on errors dot array like so it's Alex Good.
So already we can start to test this out before we do so however let's just make sure that we had already
wired this sign in router right here up to our Express application back inside of the index not t s
file to back inside of index not t s at the very top we can double check and just make sure that we
did wire up or import that router and then make sure that it actually got connected to our Express application.
Yep definitely did all right.
So now we can go back over to postmen.
We'll try to make a request to a API users sign in and supply a invalid email or password and just verify
that we're seeing some appropriate validation info.
As a matter of fact I notice I got a typo right there around supply so definitely worth doing.
Very small little tests every now and then.
I'm gonna make a request to API users sign in our first tried to supply an email that is not valid.
There we go.
So email must be valid.
If I put in an email that is valid but I have an empty password I'll see you must apply a password.
Very good.
Now if we put in some valid email and password at the request is just going to hang next because we
are not actually responding to the request at any point in time.
So this looks like a good start but as I mentioned we've now got some very much duplicated logic inside
of here.
And as you can guess there's probably gonna be many other root handlers inside of our application and
other services that are going to need to have identical logic.
So chances are we should try to extract this into some kind of helper middleware but it will take care
of this validation stuff for us automatically.
Let's take care of that in the next video.