1
00:00:00,990 --> 00:00:01,823
Instructor: In the last section,

2
00:00:01,823 --> 00:00:03,810
we were setting up our local strategy

3
00:00:03,810 --> 00:00:06,660
for helping users log into our application.

4
00:00:06,660 --> 00:00:08,250
I wanna take a second and just make sure

5
00:00:08,250 --> 00:00:09,330
that it's crystal clear

6
00:00:09,330 --> 00:00:11,310
why we're building this local strategy

7
00:00:11,310 --> 00:00:15,630
when we already have a JwtStrategy down here.

8
00:00:15,630 --> 00:00:17,160
Let's take a look at a diagram

9
00:00:17,160 --> 00:00:20,580
that illustrates our different authentication flows.

10
00:00:20,580 --> 00:00:23,280
So right now, we've kind of got really three use cases.

11
00:00:23,280 --> 00:00:26,370
We have the case in which a user is signing up,

12
00:00:26,370 --> 00:00:30,360
signing in, or making an authenticated request.

13
00:00:30,360 --> 00:00:32,400
When a user is first signing up,

14
00:00:32,400 --> 00:00:35,370
they are going to send us an email and a password.

15
00:00:35,370 --> 00:00:37,020
We're just gonna verify that that email

16
00:00:37,020 --> 00:00:38,700
is not in use and then we're going to

17
00:00:38,700 --> 00:00:40,320
return to them a token.

18
00:00:40,320 --> 00:00:43,950
In other words, we now consider them to be authenticated.

19
00:00:43,950 --> 00:00:47,010
In the case that a user is trying to sign in,

20
00:00:47,010 --> 00:00:49,470
we're assuming that they're going to send us their email

21
00:00:49,470 --> 00:00:50,700
and password.

22
00:00:50,700 --> 00:00:54,360
We're gonna verify that the email and password are correct

23
00:00:54,360 --> 00:00:56,250
using our local strategy.

24
00:00:56,250 --> 00:00:58,320
That's what we're building right now.

25
00:00:58,320 --> 00:01:00,060
And then, we'll give them a token.

26
00:01:00,060 --> 00:01:03,063
So we then consider them to be authenticated or logged in.

27
00:01:04,019 --> 00:01:05,580
Then, in the future,

28
00:01:05,580 --> 00:01:08,700
when a user wants to make an authenticated request,

29
00:01:08,700 --> 00:01:10,410
we will verify the token

30
00:01:10,410 --> 00:01:11,243
so we're gonna assume

31
00:01:11,243 --> 00:01:12,330
that they're gonna send the token along.

32
00:01:12,330 --> 00:01:15,060
We'll verify the token and give them access

33
00:01:15,060 --> 00:01:17,080
to whatever the given resource is

34
00:01:18,150 --> 00:01:19,380
that they're requesting.

35
00:01:19,380 --> 00:01:21,810
So the key here is that this verified token

36
00:01:21,810 --> 00:01:25,200
is using the JWT strategy that we already created

37
00:01:25,200 --> 00:01:27,270
but verifying an email and password

38
00:01:27,270 --> 00:01:29,370
is going to be using the local strategy

39
00:01:29,370 --> 00:01:31,170
that we're working on right now.

40
00:01:31,170 --> 00:01:32,400
I just wanna make sure that that was clear,

41
00:01:32,400 --> 00:01:34,233
why we have two strategies.

42
00:01:36,300 --> 00:01:38,670
Okay, so looking at our strategy again,

43
00:01:38,670 --> 00:01:40,980
we need to verify that this username,

44
00:01:40,980 --> 00:01:44,760
excuse me, verify this email and password are correct.

45
00:01:44,760 --> 00:01:46,530
And then, we're going to find the user

46
00:01:46,530 --> 00:01:50,370
and call this done callback with that particular user.

47
00:01:50,370 --> 00:01:51,720
And I put username in here twice

48
00:01:51,720 --> 00:01:53,280
but I really mean email.

49
00:01:53,280 --> 00:01:54,113
Okay.

50
00:01:55,080 --> 00:01:57,870
So we need to somehow figure, find this user

51
00:01:57,870 --> 00:01:59,310
and then compare the passwords.

52
00:01:59,310 --> 00:02:01,380
So we need to find our existing record

53
00:02:01,380 --> 00:02:03,630
in the database for this email

54
00:02:03,630 --> 00:02:06,300
and then compare the password to this password right here

55
00:02:06,300 --> 00:02:08,763
that the request is supplying to us.

56
00:02:09,810 --> 00:02:12,030
To find the existing user in our database

57
00:02:12,030 --> 00:02:15,120
with this email, we'll use our user model,

58
00:02:15,120 --> 00:02:17,133
which we already required at the top,

59
00:02:19,830 --> 00:02:22,500
and we'll find an existing user

60
00:02:22,500 --> 00:02:25,110
who already has this email address, okay?

61
00:02:25,110 --> 00:02:26,820
So we're assuming that if someone is trying

62
00:02:26,820 --> 00:02:27,780
to log in with an email,

63
00:02:27,780 --> 00:02:31,440
we're assuming that it's gonna already exist in our database

64
00:02:31,440 --> 00:02:32,670
so we'll search the database,

65
00:02:32,670 --> 00:02:35,313
try to find this email in there already.

66
00:02:37,470 --> 00:02:38,790
Then, we'll put our callback in.

67
00:02:38,790 --> 00:02:41,100
Remember, doing a search is asynchronous

68
00:02:41,100 --> 00:02:43,110
so we need to supply a callback.

69
00:02:43,110 --> 00:02:45,810
And it's gonna be called with an err object

70
00:02:45,810 --> 00:02:46,803
and our user.

71
00:02:48,090 --> 00:02:52,140
So first, if there is an error in the search,

72
00:02:52,140 --> 00:02:55,353
we'll just return early with an error object.

73
00:02:56,940 --> 00:02:58,200
And then, we need to handle the case

74
00:02:58,200 --> 00:02:59,850
if a user was not found,

75
00:02:59,850 --> 00:03:01,650
so if a user thinks they have an account

76
00:03:01,650 --> 00:03:03,300
but they really don't.

77
00:03:03,300 --> 00:03:06,480
In this case, we'll return done.

78
00:03:06,480 --> 00:03:08,160
There was not an error, per se,

79
00:03:08,160 --> 00:03:10,830
so we're not gonna return an error object in this case,

80
00:03:10,830 --> 00:03:12,000
but we are gonna say false.

81
00:03:12,000 --> 00:03:13,503
So user was not found.

82
00:03:15,570 --> 00:03:17,700
So now, we need to put in our logic

83
00:03:17,700 --> 00:03:21,150
that says compare passwords basically.

84
00:03:21,150 --> 00:03:23,550
This is where we're gonna compare our passwords.

85
00:03:24,390 --> 00:03:28,890
Is password, and I'm using password in reference

86
00:03:28,890 --> 00:03:32,490
to this password that was supplied by the request,

87
00:03:32,490 --> 00:03:35,043
equal to user.password?

88
00:03:36,210 --> 00:03:37,043
Okay?

89
00:03:37,043 --> 00:03:38,790
So this is the question we now need to answer.

90
00:03:38,790 --> 00:03:40,590
But if you recall,

91
00:03:40,590 --> 00:03:42,090
when we store our user,

92
00:03:42,090 --> 00:03:44,670
we hashed and salted the password.

93
00:03:44,670 --> 00:03:47,070
Remember, we've got this really long password on here

94
00:03:47,070 --> 00:03:49,890
so we can't just do a plain string comparison.

95
00:03:49,890 --> 00:03:54,890
We need to somehow decode this stored, encrypted password

96
00:03:55,020 --> 00:03:57,450
and compare it to the password that was supplied

97
00:03:57,450 --> 00:03:58,350
with our request,

98
00:03:58,350 --> 00:04:01,203
which is going to be a plain text password.

99
00:04:02,310 --> 00:04:05,370
So we need some ability to compare an encrypted password

100
00:04:05,370 --> 00:04:07,260
to a normal password.

101
00:04:07,260 --> 00:04:09,570
Let's continue with that in the next section

102
00:04:09,570 --> 00:04:11,490
because it's gonna be a fun one.

103
00:04:11,490 --> 00:04:14,310
It's gonna wrap up all the talk that we had about bcrypt.

104
00:04:14,310 --> 00:04:16,709
So let's do this comparison in the next section.