1
00:00:00,150 --> 00:00:05,280
Now that you had a chance to mess around with be corrupt in isolation we're going to actually integrate

2
00:00:05,280 --> 00:00:09,180
password hashing in to the task manager API.

3
00:00:09,180 --> 00:00:15,810
Now there are two main places where plaintext passwords are provided to our application and we can explore

4
00:00:15,810 --> 00:00:18,690
both by heading over to the user router.

5
00:00:18,860 --> 00:00:21,470
The first and the most obvious is right here.

6
00:00:21,480 --> 00:00:29,260
Post users this is when a user is created and it's impossible to create a user without providing a password.

7
00:00:29,280 --> 00:00:35,330
So when someone is signing up we definitely want to make sure to hash that plaintext password.

8
00:00:35,500 --> 00:00:37,410
The next one is down below.

9
00:00:37,410 --> 00:00:43,190
When a user is updated now they could be updated and have the password stay the same.

10
00:00:43,230 --> 00:00:45,210
Then maybe just update the name.

11
00:00:45,300 --> 00:00:51,570
But there is a chance that a new password is provided and if it is provided we want to make sure we

12
00:00:51,570 --> 00:00:52,400
hash it.

13
00:00:52,560 --> 00:00:58,350
So these are the two places where plain text passwords might be provided to our application.

14
00:00:58,350 --> 00:01:02,970
Now we're actually not going to change the code in here at all.

15
00:01:02,970 --> 00:01:10,830
Instead what we're going to do is customize the User model Mongoose supports what's known as middleware

16
00:01:10,980 --> 00:01:16,770
middleware as a way to customize the behavior of your Mongoose model and it's going to allow us to do

17
00:01:16,770 --> 00:01:19,610
some pretty interesting things to explore this.

18
00:01:19,620 --> 00:01:26,220
Let's head over to the Mongoose documentation and under guides we have a middleware with middleware

19
00:01:26,400 --> 00:01:32,300
we can register some functions to run before or after given events occur.

20
00:01:32,310 --> 00:01:33,980
So for example validate.

21
00:01:34,320 --> 00:01:39,810
I could run some code just before or just after a user is validated.

22
00:01:39,810 --> 00:01:46,500
I could also run some code just before or just after a user is saved and we have other events down below

23
00:01:46,530 --> 00:01:47,610
as well.

24
00:01:47,610 --> 00:01:55,620
In our case we want to focus on Save Our job is to run some code just before a user is saved.

25
00:01:55,620 --> 00:01:56,860
What are we going to do.

26
00:01:56,880 --> 00:02:02,980
We're gonna check if there's a plain text password and if there is we'll go ahead and hash it.

27
00:02:03,060 --> 00:02:09,090
Now to actually get this done we'll need to head over to the user model and do a little bit of restructuring

28
00:02:09,300 --> 00:02:11,880
to take advantage of this more advanced feature.

29
00:02:11,970 --> 00:02:17,730
When we create a mongoose model we're passing an object in as the second argument to model that's the

30
00:02:17,730 --> 00:02:23,830
object that starts right here and runs all the way down to the end of our attribute definitions.

31
00:02:23,820 --> 00:02:30,510
Now when we pass an object in as that second argument behind the scenes Mongoose converts it into what's

32
00:02:30,510 --> 00:02:36,230
known as a schema in order to take advantage of the middleware functionality.

33
00:02:36,290 --> 00:02:39,860
All we have to do is create this schema first and pass that in.

34
00:02:39,990 --> 00:02:45,480
It's going to require about one line of additional code to get done but once it's done we'll be able

35
00:02:45,480 --> 00:02:47,680
to use more advanced features.

36
00:02:47,700 --> 00:02:54,300
So right here what we're going to do is create a constant called User schema and we're going to set

37
00:02:54,300 --> 00:03:02,190
it up by using the new operator with the following Mongoose dot capital S schema and we're going to

38
00:03:02,190 --> 00:03:07,530
pass to it an object which defines all of the properties for that schema.

39
00:03:07,530 --> 00:03:12,210
Now that's just the object we have down below so we'll take this object.

40
00:03:12,210 --> 00:03:16,200
The second argument to model I'll highlight the entire thing.

41
00:03:16,290 --> 00:03:22,440
Cut it out of its current location and paste it right here as the first and only argument to the schema

42
00:03:22,440 --> 00:03:23,510
method.

43
00:03:23,510 --> 00:03:30,720
Now when I do that we have access to the user schema and all we're going to do is pass that in as the

44
00:03:30,720 --> 00:03:32,930
second argument to model.

45
00:03:32,970 --> 00:03:38,670
So if we were to pass an object in Mongoose was doing that behind the scenes anyways in this case we

46
00:03:38,670 --> 00:03:42,340
are creating a separate schema and a separate model.

47
00:03:42,420 --> 00:03:46,390
And this is going to allow us to take advantage of middleware.

48
00:03:46,440 --> 00:03:53,010
So right here what we're going to do is use a method on user schema to set the middleware up.

49
00:03:53,250 --> 00:03:59,890
That's user schema dot and there are two methods accessible to us for middleware.

50
00:03:59,970 --> 00:04:06,000
We have three for doing something before an event like before validation or before saving.

51
00:04:06,330 --> 00:04:13,260
And we have a post for doing something just after an event such as after the user has been saved.

52
00:04:13,260 --> 00:04:15,930
In our case we want to do something before.

53
00:04:15,930 --> 00:04:19,680
So we'll be using pre and we passed to two arguments.

54
00:04:19,680 --> 00:04:24,360
The first is the name of the event that would be save in our case.

55
00:04:24,360 --> 00:04:28,380
And the second is the function to run right here.

56
00:04:28,380 --> 00:04:35,520
This needs to be a standard function not an arrow function because the this binding plays an important

57
00:04:35,520 --> 00:04:40,160
role and as we know arrow functions don't bind this.

58
00:04:40,170 --> 00:04:45,760
Now I will be using async await inside of here so we can go ahead and set that up.

59
00:04:46,110 --> 00:04:51,120
And we also get access to an argument which I'll talk about in a moment called next.

60
00:04:51,120 --> 00:04:54,020
For now let's just go ahead and name it.

61
00:04:54,090 --> 00:05:01,360
So inside of here we have access to the value on this which is equal to the that's being saved.

62
00:05:01,370 --> 00:05:05,950
So right here we're saying I want to do something before users are saved.

63
00:05:05,960 --> 00:05:10,610
This gives us access to the individual user that's about to be saved.

64
00:05:10,940 --> 00:05:14,540
Now it's kind of annoying to reference this throughout our function.

65
00:05:14,540 --> 00:05:19,700
So what I'll typically do though it's not required is create a new variable cost.

66
00:05:19,700 --> 00:05:21,400
User equals this.

67
00:05:21,440 --> 00:05:26,460
Now I can access user down below which is a bit easier to understand.

68
00:05:26,480 --> 00:05:29,480
Now let's take a quick moment to talk about next.

69
00:05:29,540 --> 00:05:33,690
The whole point of this is to run some code before a user is saved.

70
00:05:33,770 --> 00:05:36,630
But how does it know when we're done running our code.

71
00:05:36,650 --> 00:05:39,260
Now it could just say when the function is over.

72
00:05:39,260 --> 00:05:43,310
But that wouldn't account for any asynchronous process which might be occurring.

73
00:05:43,640 --> 00:05:45,700
So that's why next is provided.

74
00:05:45,830 --> 00:05:48,830
We simply call next when we're done right here.

75
00:05:48,860 --> 00:05:51,690
I'm going to call next at the end of the function.

76
00:05:51,860 --> 00:05:53,910
Now if we never call next.

77
00:05:54,020 --> 00:05:55,850
It's just going to hang forever.

78
00:05:55,850 --> 00:06:01,190
Thinking that we're still running some code before we save the user and it will never actually save

79
00:06:01,190 --> 00:06:02,020
the user.

80
00:06:02,090 --> 00:06:08,000
So it's really important to make sure that next gets called now right here in between.

81
00:06:08,000 --> 00:06:13,600
This is where we want to go ahead and hash the password before we do anything like that.

82
00:06:13,610 --> 00:06:21,230
Let's go ahead and just use console dot log to print a message just before saving what we're gonna do

83
00:06:21,380 --> 00:06:27,320
is fire off some operations from postman and watch that message printed in the terminal down below with

84
00:06:27,320 --> 00:06:28,460
the programs saved.

85
00:06:28,460 --> 00:06:34,290
I'll head over to the postman and we're going to start by going over to the create user request.

86
00:06:34,310 --> 00:06:40,190
This is one of the two places where we can provide a plain text password and if I fire things off we

87
00:06:40,190 --> 00:06:42,160
can see what we get in the terminal.

88
00:06:42,290 --> 00:06:44,840
So first off will note that things did finish.

89
00:06:44,840 --> 00:06:51,890
We have the data down below and our 2 0 1 status and over inside a Visual Studio code what do I get

90
00:06:52,190 --> 00:07:00,140
I get just before saving printing and on user I could access the various pieces of data that were provided

91
00:07:00,140 --> 00:07:06,020
for the user such as the name email or password and we'll do that in just a moment.

92
00:07:06,140 --> 00:07:12,890
Now currently things are not going to work if we were to try to update the user so I just created this

93
00:07:12,890 --> 00:07:13,940
brand new user.

94
00:07:14,120 --> 00:07:18,980
Let's grab their I.D. and try to update something I'm going to take the I.D..

95
00:07:19,340 --> 00:07:22,880
Bring it over to the update user request and paste it in.

96
00:07:22,910 --> 00:07:30,100
Up above from there we're going to change one of the attributes and I can leave it as it currently is

97
00:07:30,330 --> 00:07:33,310
where I'm changing the name to Jess.

98
00:07:33,310 --> 00:07:36,910
Now if I fire that off what are we going to see down below.

99
00:07:36,910 --> 00:07:37,710
Things work.

100
00:07:37,720 --> 00:07:41,800
The name is now Jess and everything else looks as expected.

101
00:07:41,830 --> 00:07:50,050
The problem is that over in Visual Studio code we didn't get our message a second time so certain Mongoose

102
00:07:50,050 --> 00:07:56,710
queries bypassed more advanced features like middleware which means that if we want to use them consistently

103
00:07:56,890 --> 00:08:00,360
we just have to do a tiny bit of restructuring.

104
00:08:00,430 --> 00:08:05,120
So all we're going to do is head over to that update route in the router file.

105
00:08:05,260 --> 00:08:11,590
I have that just down below and we're going to make a small change a change to how we perform what's

106
00:08:11,590 --> 00:08:12,960
done on this line.

107
00:08:13,060 --> 00:08:20,940
The actual update process the find by I.D. and update method bypasses mongoose.

108
00:08:21,010 --> 00:08:24,500
It performs a direct operation on the database.

109
00:08:24,520 --> 00:08:30,190
That's why we even had to set a special option for running the validators.

110
00:08:30,220 --> 00:08:31,300
We can go ahead and do it.

111
00:08:31,300 --> 00:08:37,060
The more traditional Mongoose way to make sure that our middleware runs correctly we're going to replace

112
00:08:37,060 --> 00:08:39,710
one line of code with three lines of code.

113
00:08:39,730 --> 00:08:41,840
So not a big change.

114
00:08:41,950 --> 00:08:46,620
The first thing we need to do is create a variable const user.

115
00:08:46,810 --> 00:08:53,050
And what we're going to do is find that user by I.D. so it still starts off in a very similar way.

116
00:08:53,080 --> 00:09:01,240
I'll use a wait with user dot find by I.D. And right here we just passed that I.D. in exactly as we

117
00:09:01,240 --> 00:09:07,750
had it before request dot pyramids dot I.D. which was the value provided right here.

118
00:09:07,780 --> 00:09:09,970
Now we have access to the user.

119
00:09:10,090 --> 00:09:16,690
So we have access to an instance of our user model and it's time to update the properties that are actually

120
00:09:16,690 --> 00:09:17,740
being changed.

121
00:09:17,740 --> 00:09:25,240
So for example changing the name would be me setting user dot name equal to the new value like something

122
00:09:25,240 --> 00:09:26,230
else.

123
00:09:26,230 --> 00:09:31,990
Now in this case we can't hard code us updating those properties because it could be a different set

124
00:09:31,990 --> 00:09:34,240
of updates every single time.

125
00:09:34,240 --> 00:09:40,480
So all we're going to do is iterate over our updates array the list of updates that are actually being

126
00:09:40,480 --> 00:09:43,300
applied and will apply them right here.

127
00:09:43,360 --> 00:09:47,190
We will use updates which is an array dot for each.

128
00:09:47,190 --> 00:09:48,520
To get that done.

129
00:09:48,670 --> 00:09:52,870
So we provide our callback function which gets called one time for each update.

130
00:09:52,870 --> 00:09:58,600
We're trying to apply and we have access to the individual update field right here.

131
00:09:58,600 --> 00:10:01,780
Remember updates was an array of strings.

132
00:10:01,810 --> 00:10:04,490
So what we're getting right here is a string.

133
00:10:04,540 --> 00:10:10,360
It would be something like name email password or whatever field they're trying to update.

134
00:10:10,360 --> 00:10:16,900
Now what we need to do is correctly set the property on user for that we'll use bracket notation.

135
00:10:16,900 --> 00:10:22,870
So here I'm updating a property on user but it's dynamic so I can't type it out like name because I

136
00:10:22,870 --> 00:10:24,100
don't know what it is.

137
00:10:24,130 --> 00:10:26,680
It's stored on that update variable.

138
00:10:26,680 --> 00:10:33,250
So we'll use bracket notation to access a property dynamically in this case we're accessing the property

139
00:10:33,520 --> 00:10:36,250
whose name it comes from the update variable.

140
00:10:36,250 --> 00:10:41,770
Now we're going to set that equal to the value the user passed in so request body.

141
00:10:41,860 --> 00:10:47,920
And once again we can't use dot notation because we would have to explicitly know the property and it's

142
00:10:47,920 --> 00:10:49,010
going to change.

143
00:10:49,030 --> 00:10:52,030
So we'll use bracket notation like the following.

144
00:10:52,180 --> 00:10:55,780
This is going to achieve the exact same thing but it's dynamic.

145
00:10:55,810 --> 00:11:01,890
So if the values they're updating and the Keys they're updating change it'll keep working over time.

146
00:11:01,900 --> 00:11:07,150
Now we could always take advantage of these shorthand syntax by grabbing this expression and taking

147
00:11:07,150 --> 00:11:11,200
it up above removing the curly braces and pasting it in.

148
00:11:11,440 --> 00:11:14,820
And the last thing we do is something we've done plenty of times before.

149
00:11:14,890 --> 00:11:18,250
I just await a call to user dot save.

150
00:11:18,490 --> 00:11:23,890
And this is where our middleware is actually going to get executed now that we have this in place.

151
00:11:23,920 --> 00:11:26,980
Let's go ahead and actually make sure we get our message printing.

152
00:11:27,320 --> 00:11:33,540
So over inside of postmen I'm going to run the exact same update operation though let's change the name.

153
00:11:34,000 --> 00:11:39,540
I'll change it from Jess to Jessica I'll fire it off down below it does indeed work.

154
00:11:39,550 --> 00:11:46,150
And the name has indeed changed correctly but over inside a visual studio code we're now getting our

155
00:11:46,150 --> 00:11:47,670
middleware running.

156
00:11:47,680 --> 00:11:52,930
So this is a small adjustment that's required in order to get middleware to consistently run.

157
00:11:53,140 --> 00:11:59,410
Now that it is consistently running we'll do what we actually want to do which is to hash the password.

158
00:11:59,590 --> 00:12:01,940
And that's going to happen right here.

159
00:12:01,960 --> 00:12:08,170
Now the first thing we want to do is make sure the password is actually being changed if the password

160
00:12:08,170 --> 00:12:09,480
is already hashed.

161
00:12:09,490 --> 00:12:11,830
We don't want to hash it again.

162
00:12:11,830 --> 00:12:18,010
We only want to hash the password if it's been modified by the user and Mongoose gives us a really easy

163
00:12:18,010 --> 00:12:20,400
way to figure out if that's the case.

164
00:12:20,410 --> 00:12:25,100
So what I'll be doing is setting up an if condition in here.

165
00:12:25,110 --> 00:12:32,340
This is where we'll hash the password but only under the following condition if the user has a modified

166
00:12:32,370 --> 00:12:39,870
password property user dot is modified as the method we can use and we pass in the name of the field

167
00:12:39,870 --> 00:12:40,740
we're looking for.

168
00:12:40,740 --> 00:12:44,730
In this case we're looking to see if password was modified.

169
00:12:44,730 --> 00:12:48,030
This will be true when the user is first created.

170
00:12:48,180 --> 00:12:54,080
And it will also be true if the user is being updated and password was one of the things changed in

171
00:12:54,080 --> 00:12:54,640
here.

172
00:12:54,660 --> 00:12:58,400
We can actually hash the password and we've done that before.

173
00:12:58,440 --> 00:13:06,210
I'll be setting user dot password equal to a hash I'll use a weight with the following that is B crypt

174
00:13:06,270 --> 00:13:09,150
dot hash not ash.

175
00:13:09,150 --> 00:13:12,410
And we're going to pass in those two arguments.

176
00:13:12,450 --> 00:13:14,760
The first is the thing to hash.

177
00:13:14,880 --> 00:13:17,550
I have that on user dot password.

178
00:13:17,550 --> 00:13:21,650
And the second is the number of rounds and once again I'll use eight.

179
00:13:21,660 --> 00:13:27,840
So here we're taking the plain text password and hashing it then using that hash value to override the

180
00:13:27,840 --> 00:13:29,810
plaintext value.

181
00:13:29,820 --> 00:13:35,860
Now with this in place the only other thing we need to change in this file is to import B correct.

182
00:13:35,880 --> 00:13:36,650
So up above.

183
00:13:36,660 --> 00:13:43,000
Let's get that done before saving and running it a new constant B script equals.

184
00:13:43,200 --> 00:13:47,920
We'll use require grabbing the B script J.S. NPM module.

185
00:13:47,920 --> 00:13:55,110
Now we can actually test things out and make sure the password is getting hashed so over inside of robo

186
00:13:55,110 --> 00:13:57,360
three T in the user's collection.

187
00:13:57,360 --> 00:14:01,260
I have a few different users all with plain text passwords.

188
00:14:01,260 --> 00:14:04,080
Let's create a fifth one right here.

189
00:14:04,170 --> 00:14:10,450
I'll be heading over to create user and I'll be firing off the exact same request I fired off before.

190
00:14:10,560 --> 00:14:14,250
Still providing the plaintext password when I send that off.

191
00:14:14,250 --> 00:14:14,960
What do I get.

192
00:14:14,970 --> 00:14:21,480
I get a two 0 1 and down below I can see not a plain text password but a hashed one.

193
00:14:21,480 --> 00:14:26,040
Now for the moment we're still going to send the password back as part of the response.

194
00:14:26,040 --> 00:14:29,610
Later on we'll fix that locking down the password even more.

195
00:14:29,610 --> 00:14:34,860
The goal for now though is to just hash it and that's what we have now over in the database.

196
00:14:34,860 --> 00:14:38,210
We should see the hash value showing up here as well.

197
00:14:38,250 --> 00:14:41,860
And if I refresh the collection that is exactly what I have.

198
00:14:42,000 --> 00:14:48,750
That last user document does indeed have a password but it is the hashed one we saw before.

199
00:14:48,780 --> 00:14:52,650
Now let's go ahead and update the user to make sure that works too.

200
00:14:52,740 --> 00:14:59,530
So I already have their I.D. of that old user as part of the request for update user over here we found

201
00:14:59,550 --> 00:15:05,880
that a few moments ago what I'll do is change the name back to Andrew but I'm also going to change that

202
00:15:05,880 --> 00:15:15,280
password right here I'll set a new value for password and I'll make the value something like test one

203
00:15:15,290 --> 00:15:19,040
two three and then I'll use some special characters.

204
00:15:19,060 --> 00:15:22,810
Now if I go ahead and fire that off what are we going to see down below.

205
00:15:22,810 --> 00:15:27,790
I can see that things did work and we now have a hashed password value.

206
00:15:28,150 --> 00:15:33,910
So when someone creates a new user or when they update their existing user if a plain text password

207
00:15:33,940 --> 00:15:40,330
is provided it is indeed going to get hashed and middleware allows us to enforce that without having

208
00:15:40,330 --> 00:15:46,930
to add this password hashing logic into multiple places like the two routes that are actually related

209
00:15:47,080 --> 00:15:48,330
to this situation.

210
00:15:48,370 --> 00:15:51,110
We just provide it once and it works everywhere.

211
00:15:51,220 --> 00:15:53,140
So that's where we're going to stop for this one.

212
00:15:53,140 --> 00:15:56,970
But before we go there is a quick challenge I'd like you to work through.

213
00:15:56,980 --> 00:16:01,540
Your job is going to be to make a change to the task router.

214
00:16:01,630 --> 00:16:02,910
We have our post.

215
00:16:02,920 --> 00:16:03,520
Excuse me.

216
00:16:03,520 --> 00:16:10,510
Patch request right here for updating a task and what I'd like you to do is alter the logic we use for

217
00:16:10,510 --> 00:16:11,420
updating it.

218
00:16:11,500 --> 00:16:17,680
Now currently we're not using any middleware for task but if we were to it would be nice to use methods

219
00:16:17,680 --> 00:16:20,590
that make sure that middleware actually runs.

220
00:16:20,590 --> 00:16:24,020
So we'll be doing the same thing here that we did for user.

221
00:16:24,040 --> 00:16:27,340
So your goal is to change how tasks are updated.

222
00:16:27,340 --> 00:16:34,960
Step 1 instead of using find by I.D. and update you will first find the task then you'll use for each

223
00:16:34,960 --> 00:16:38,230
to apply all of the updates onto the task.

224
00:16:38,230 --> 00:16:44,620
Finally you'll save it and then you'll test your work from postmen make an update to an existing task

225
00:16:44,620 --> 00:16:47,340
and ensure that it gets applied correctly.

226
00:16:47,530 --> 00:16:49,490
So take some time to knock that out.

227
00:16:49,540 --> 00:16:55,930
Feel free to use what we did with the user router as a reference and when you're done come back and

228
00:16:55,930 --> 00:16:56,560
click play

229
00:17:00,600 --> 00:17:01,590
how that go.

230
00:17:01,590 --> 00:17:08,090
Let's go ahead and kick things off together down below we have the one line we had before.

231
00:17:08,130 --> 00:17:13,170
I'm going to comment that out and instead we'll go ahead and do things the new way.

232
00:17:13,170 --> 00:17:15,870
So first stop is defined that task.

233
00:17:15,870 --> 00:17:22,950
I will create a new task variable much like we did for the user router over here and I'll use a wait

234
00:17:23,010 --> 00:17:24,510
with task Dot.

235
00:17:24,510 --> 00:17:31,100
Find a buy I.D. passing the I.D. in exactly like we had done before.

236
00:17:31,110 --> 00:17:33,630
Next up we want to apply those updates.

237
00:17:33,630 --> 00:17:40,200
I'll be using updates dot for each to loop over them we'll get access to the individual update and like

238
00:17:40,200 --> 00:17:41,490
we did before.

239
00:17:41,520 --> 00:17:49,670
I'll be setting the property on task equal to the value they passed in request that body using bracket

240
00:17:49,670 --> 00:17:51,990
notation to get it dynamically.

241
00:17:52,190 --> 00:17:58,340
And the only other thing we needed to do was make sure to save the individual task so a weight task

242
00:17:58,400 --> 00:17:59,590
dot save.

243
00:17:59,600 --> 00:18:01,040
And we're done.

244
00:18:01,040 --> 00:18:03,840
I'll remove the old line down below.

245
00:18:03,950 --> 00:18:05,740
I'm going to save the file.

246
00:18:05,750 --> 00:18:11,900
Actually I'll also remove the challenge comments up above now I'll save the file and we can test our

247
00:18:11,900 --> 00:18:15,050
work to make sure that updates still function.

248
00:18:15,050 --> 00:18:18,610
The first thing I'm going to do is get a task I.D..

249
00:18:18,740 --> 00:18:26,440
So right here I will read all of the tasks I have a single one I'll grab its I.D. and I'll change the

250
00:18:26,440 --> 00:18:29,000
completed value from true to false.

251
00:18:29,020 --> 00:18:31,470
I'll then head over to update task.

252
00:18:31,600 --> 00:18:37,820
I'll put that I.D. right inside of the U.R.L. and I will switch it from true over to false.

253
00:18:37,840 --> 00:18:43,330
So I'm only changing the completed property now if I go ahead and send that off down below I do get

254
00:18:43,330 --> 00:18:46,150
my 200 status code which is fantastic.

255
00:18:46,240 --> 00:18:51,610
And any response body I can see my updated task and everything looks correct.

256
00:18:51,610 --> 00:18:57,580
The other fields haven't been altered and the one that I did update did indeed change meaning that our

257
00:18:57,580 --> 00:19:01,070
code is still working even though we've refactor it.

258
00:19:01,270 --> 00:19:06,580
That's where we're gonna stop for this video in the next video we're going to continue on talking about

259
00:19:06,640 --> 00:19:10,270
authentication and we'll move on to the next topic.

260
00:19:10,270 --> 00:19:15,190
We're going to cover which is the concept of logging a user in.

261
00:19:15,280 --> 00:19:17,590
We'll figure out how we're going to get that done.

262
00:19:17,590 --> 00:19:19,770
Let's go ahead and jump right in.