1
00:00:00,510 --> 00:00:06,380
We have now spent a very long time around sign up but we are all done really for real this time.

2
00:00:06,470 --> 00:00:09,050
So now going to start to move on to our next root handler.

3
00:00:09,050 --> 00:00:12,470
And believe me everything else inside of this service is going to go forward.

4
00:00:12,470 --> 00:00:13,880
Much much more quickly.

5
00:00:13,910 --> 00:00:18,320
We've really covered all the really big topics we need to be aware of and we get to breeze through everything

6
00:00:18,320 --> 00:00:19,390
else inside of here.

7
00:00:19,710 --> 00:00:24,950
So in this video we're going to start to put together our sign in roots so our ReACT application or

8
00:00:25,010 --> 00:00:30,010
right now postman is going to make a request to sign into our application when they do so they're going

9
00:00:30,010 --> 00:00:35,100
to supply an email and password and then we're going to go through the following series of steps we're

10
00:00:35,100 --> 00:00:40,950
going to first take a look into our Mongo DB database and see if a user with this email exists.

11
00:00:40,950 --> 00:00:45,690
If the email that was supplied and said the request doesn't exist or is not tied to an user inside of

12
00:00:45,690 --> 00:00:48,600
our database then it must be an invalid log in request.

13
00:00:48,840 --> 00:00:52,500
So we will respond with an error immediately if that is the case.

14
00:00:52,590 --> 00:00:57,300
Now assuming that we do find a user we're going to compare the passwords of the stored user and the

15
00:00:57,360 --> 00:01:00,350
supplied password present inside that request.

16
00:01:00,420 --> 00:01:05,430
And remember we already put together a method to inside that password service thing or that password

17
00:01:05,430 --> 00:01:11,460
service class to handle password comparison if the two passwords are identical then Hey fantastic.

18
00:01:11,490 --> 00:01:16,760
We'll now consider this user to be logged in so that we are going to send them a Jason web token in

19
00:01:16,770 --> 00:01:22,240
that cookie using the same kind of strategy as what we did back inside of sign up over here.

20
00:01:23,690 --> 00:01:23,930
OK.

21
00:01:23,960 --> 00:01:25,880
So with all that mind let's get to it.

22
00:01:25,890 --> 00:01:29,260
I'm gonna flip on over to my sign and to file.

23
00:01:29,360 --> 00:01:32,450
We've already got a little bit of code inside of your already.

24
00:01:32,450 --> 00:01:37,130
So we'll go ahead and start to augment this the person we're going to do is do some validation on the

25
00:01:37,130 --> 00:01:49,270
incoming request so I'm going to add in an import statement or body from Express validator.

26
00:01:49,270 --> 00:01:54,790
Remember this is a method that can be used as a middleware to validate incoming data on the body of

27
00:01:54,790 --> 00:01:56,560
this post request.

28
00:01:56,560 --> 00:02:05,510
So I'm gonna put an array inside of here that's to organize these different validation functions.

29
00:02:05,660 --> 00:02:12,340
We're going to do some very similar validation to what we did back inside a sign up so let's do a check

30
00:02:12,400 --> 00:02:19,630
for email we'll make sure that it looks like an email and we'll put in a custom message if something

31
00:02:19,630 --> 00:02:27,470
is wrong with it so we'll say email must be valid then as a second entry inside this array so note the

32
00:02:27,480 --> 00:02:35,910
comma over here we will put in body we're gonna check the password this time we'll go ahead and do that

33
00:02:35,910 --> 00:02:41,010
sanitization step of trimming it to remove any spaces on the left or the right hand side of the supplied

34
00:02:41,010 --> 00:02:47,430
password in this case we do not need to check to see if the length is valid because our validation rules

35
00:02:47,430 --> 00:02:53,610
or exactly what a password is might change over time it might be that at some point in the past we allowed

36
00:02:53,610 --> 00:02:59,940
passwords all the way up to 30 characters whereas now the limit or the maximum is 20 if we just arbitrarily

37
00:02:59,940 --> 00:03:04,650
put on some validation step on the password right here that would lock out any existing users who do

38
00:03:04,650 --> 00:03:08,150
not or who have passwords that don't follow these rules.

39
00:03:08,160 --> 00:03:13,650
So we will however require that a password is supplied so to check for that we're going gonna put in

40
00:03:13,710 --> 00:03:20,270
a check right here we're gonna look for is or is it not empty like so.

41
00:03:20,990 --> 00:03:23,350
So if the password that is supplied is an empty string.

42
00:03:23,390 --> 00:03:27,090
This is going to throw in their will then put on a custom message.

43
00:03:27,090 --> 00:03:38,280
Once again we'll say something like you must apply a password that will work gets that looks good to

44
00:03:38,310 --> 00:03:46,490
now we'll go down into our actual body down here going to delete that resort send for now you'll notice

45
00:03:46,490 --> 00:03:49,040
that we are getting an air around rec and rest now.

46
00:03:49,280 --> 00:03:54,170
That's because typescript is no longer doing some type in inference for us which it was able to do when

47
00:03:54,170 --> 00:03:57,010
we only had two arguments being passed into post.

48
00:03:57,200 --> 00:04:04,750
So just as we did before back inside of sign up we have to import these types of requests and response

49
00:04:04,810 --> 00:04:13,360
from Express at the very top and then use those types to annotate these arguments the request and response

50
00:04:16,330 --> 00:04:19,690
then inside of here once again just like we did back inside of sign up.

51
00:04:19,690 --> 00:04:25,130
We need to take a look and see if anything went wrong during that validation attempt.

52
00:04:25,180 --> 00:04:30,310
So we essentially need to duplicate the exact same logic that we've got over inside of our sign up request

53
00:04:30,310 --> 00:04:32,830
handler right here.

54
00:04:32,860 --> 00:04:35,770
It's kind of unfortunate to have to duplicate the stuff directly over.

55
00:04:35,770 --> 00:04:40,750
So as you imagine this might be a good location or a good time to try to figure out how to make this

56
00:04:40,810 --> 00:04:43,350
error checking code a little bit more reusable.

57
00:04:43,420 --> 00:04:45,880
But right now let's just rewrite the same thing.

58
00:04:46,710 --> 00:04:54,590
So I'm going to check to see if there are any errors by doing a validation result on the incoming request

59
00:04:55,190 --> 00:05:01,470
validation result is a function that is coming from that express validator library up here so right

60
00:05:01,500 --> 00:05:08,960
after body we're gonna make sure we also import validation results that's going to give us back any

61
00:05:08,960 --> 00:05:11,980
errors on that request.

62
00:05:11,990 --> 00:05:13,760
Well then check to see if it is empty.

63
00:05:13,790 --> 00:05:15,830
So this thing is not empty

64
00:05:19,420 --> 00:05:20,770
then something's wrong.

65
00:05:20,770 --> 00:05:26,230
We should throw in air and remember we put together an error specifically for this purpose instead of

66
00:05:26,230 --> 00:05:27,410
our ears directory.

67
00:05:27,490 --> 00:05:31,040
There is that error we had put together of request validation error.

68
00:05:31,150 --> 00:05:37,170
So let's re import that into this file and we get through it from right here at the top and going to

69
00:05:37,200 --> 00:05:46,140
imports request validation error from up one directory errors request validation error

70
00:05:50,140 --> 00:05:51,380
then back down here.

71
00:05:51,490 --> 00:05:59,410
OK if the errors is not empty row new request validation error and remember the requirement here is

72
00:05:59,410 --> 00:06:07,990
we pass in the array of errors we'll pass on errors dot array like so it's Alex Good.

73
00:06:08,110 --> 00:06:13,450
So already we can start to test this out before we do so however let's just make sure that we had already

74
00:06:13,480 --> 00:06:18,730
wired this sign in router right here up to our Express application back inside of the index not t s

75
00:06:18,730 --> 00:06:24,850
file to back inside of index not t s at the very top we can double check and just make sure that we

76
00:06:24,850 --> 00:06:30,940
did wire up or import that router and then make sure that it actually got connected to our Express application.

77
00:06:30,970 --> 00:06:33,280
Yep definitely did all right.

78
00:06:33,280 --> 00:06:35,620
So now we can go back over to postmen.

79
00:06:35,720 --> 00:06:42,230
We'll try to make a request to a API users sign in and supply a invalid email or password and just verify

80
00:06:42,230 --> 00:06:44,760
that we're seeing some appropriate validation info.

81
00:06:45,020 --> 00:06:49,370
As a matter of fact I notice I got a typo right there around supply so definitely worth doing.

82
00:06:49,370 --> 00:06:51,860
Very small little tests every now and then.

83
00:06:52,050 --> 00:07:04,310
I'm gonna make a request to API users sign in our first tried to supply an email that is not valid.

84
00:07:04,320 --> 00:07:04,710
There we go.

85
00:07:04,740 --> 00:07:05,940
So email must be valid.

86
00:07:06,820 --> 00:07:15,070
If I put in an email that is valid but I have an empty password I'll see you must apply a password.

87
00:07:15,070 --> 00:07:16,150
Very good.

88
00:07:16,150 --> 00:07:21,540
Now if we put in some valid email and password at the request is just going to hang next because we

89
00:07:21,540 --> 00:07:25,160
are not actually responding to the request at any point in time.

90
00:07:25,220 --> 00:07:30,290
So this looks like a good start but as I mentioned we've now got some very much duplicated logic inside

91
00:07:30,290 --> 00:07:30,960
of here.

92
00:07:31,100 --> 00:07:35,330
And as you can guess there's probably gonna be many other root handlers inside of our application and

93
00:07:35,330 --> 00:07:38,460
other services that are going to need to have identical logic.

94
00:07:38,570 --> 00:07:43,430
So chances are we should try to extract this into some kind of helper middleware but it will take care

95
00:07:43,430 --> 00:07:46,030
of this validation stuff for us automatically.

96
00:07:46,190 --> 00:07:47,990
Let's take care of that in the next video.