1
00:00:00,000 --> 00:00:04,614
[MUSIC]

2
00:00:04,614 --> 00:00:09,792
We had already developed a full-fledged
REST API server using Express and

3
00:00:09,792 --> 00:00:12,026
MongoDB as part of this course.

4
00:00:12,026 --> 00:00:16,881
In order for the server to be able to
communicate meaningfully with our client,

5
00:00:16,881 --> 00:00:21,892
we will make a few minor adjustments to it
so that it returns the right kind of data.

6
00:00:21,892 --> 00:00:26,063
So that our client implementation
can work more efficiently

7
00:00:26,063 --> 00:00:29,370
with the data returned
from our server-side.

8
00:00:29,370 --> 00:00:30,427
So to do that,

9
00:00:30,427 --> 00:00:35,724
let's work on a few adjustments to
our server-side in this exercise.

10
00:00:37,478 --> 00:00:43,220
Going to our server in the editor,
before we start working on the server,

11
00:00:43,220 --> 00:00:48,497
I would suggest that you download
all the images that I have provided

12
00:00:48,497 --> 00:00:53,260
as a zip file in the exercise
resources called images.zip.

13
00:00:53,260 --> 00:00:56,530
Unzip the file and
then obtain all the images from there, and

14
00:00:56,530 --> 00:01:03,440
then copy those images into the public
images folder in our server.

15
00:01:03,440 --> 00:01:08,980
So you see that here I have copied
all the images into my public images

16
00:01:08,980 --> 00:01:10,580
folder here already.

17
00:01:10,580 --> 00:01:15,120
Because our server is the one that is
going to serve up all these images for

18
00:01:15,120 --> 00:01:17,460
our client application.

19
00:01:17,460 --> 00:01:22,820
Next, we go to the cors and
adjust that whitelist, here.

20
00:01:22,820 --> 00:01:27,919
So for our Angular client application,
if we start it up

21
00:01:27,919 --> 00:01:33,571
with the ng serve command,
it runs at localhost:4200.

22
00:01:33,571 --> 00:01:36,196
So any requests coming in from our Angular

23
00:01:36,196 --> 00:01:40,750
application to the server will
carry that as their origin there.

24
00:01:40,750 --> 00:01:44,710
So that is why I'm going to
add that into my whitelist, so

25
00:01:44,710 --> 00:01:50,310
that any cors problems will
be addressed automatically.

26
00:01:50,310 --> 00:01:54,848
So going into that cors.js file,

27
00:01:54,848 --> 00:01:59,698
in my whitelist, here, let me add in

28
00:01:59,698 --> 00:02:08,371
the http://localhost:, 4200.

29
00:02:08,371 --> 00:02:12,503
And this is the origin from which
all my Angular client will be

30
00:02:12,503 --> 00:02:16,690
originating the request
that come to this server.

31
00:02:16,690 --> 00:02:22,020
So that way, my cors will not cause
problems for may Angular client.

32
00:02:22,020 --> 00:02:27,760
Next, we need to update a few
of the routes to handle

33
00:02:27,760 --> 00:02:32,760
the query parameters, and
also a few minor other adjustments.

34
00:02:32,760 --> 00:02:35,905
Let me start with
the promoRouter.js files.

35
00:02:35,905 --> 00:02:39,760
So that is simple to get updated.

36
00:02:39,760 --> 00:02:44,790
So going to the promoRouter.js file,
in the promoRouter file, for

37
00:02:44,790 --> 00:02:47,960
the get request that we get here,

38
00:02:47,960 --> 00:02:52,400
instead of doing Promotions.find
with an empty JavaScript,

39
00:02:52,400 --> 00:02:57,256
here I would supply the req.query as

40
00:02:57,256 --> 00:03:02,470
the parameter to that
Promotions.find here.

41
00:03:02,470 --> 00:03:07,650
Same thing with the leaderRouter also, so
let me go to the leaderRouter.js file.

42
00:03:07,650 --> 00:03:09,786
And in the leaderRouter also,

43
00:03:09,786 --> 00:03:14,642
here where you find Leaders.find
with the empty JavaScript object.

44
00:03:14,642 --> 00:03:18,423
Instead, replace that with that req.query,
so

45
00:03:18,423 --> 00:03:21,852
that the query parameters
will be passed in.

46
00:03:21,852 --> 00:03:26,430
So this is where we will
pass in the featured column

47
00:03:26,430 --> 00:03:29,487
through as the query parameter.

48
00:03:29,487 --> 00:03:34,678
Now having adjusted these two,
let's now work on the dish route,

49
00:03:34,678 --> 00:03:41,090
so going to dishRouter.js file, even in
the dishRouter, the same update here.

50
00:03:41,090 --> 00:03:48,920
So going to this Dishes.find in the get
method here, change that to req.query.

51
00:03:48,920 --> 00:03:52,987
So with this,
my dishRouter update has been completed.

52
00:03:52,987 --> 00:03:57,664
So we have now updated the promoRouter,
the readerRouter, and

53
00:03:57,664 --> 00:04:02,784
the dishRouter, then we will move
on to update that favoriteRouter.

54
00:04:02,784 --> 00:04:07,519
Now you would have implemented
the favorite router as part of your

55
00:04:07,519 --> 00:04:09,500
fourth assignment.

56
00:04:09,500 --> 00:04:12,306
Now in the favoriteRouter,
you will see that for

57
00:04:12,306 --> 00:04:16,618
the favoriteRouter I'm not showing
you the remaining parter because that

58
00:04:16,618 --> 00:04:19,437
you should have done as
part of your assignment.

59
00:04:19,437 --> 00:04:22,925
Let me first draw your
attention to the get method for

60
00:04:22,925 --> 00:04:26,422
the favoriteRouter.route("/:dishId').

61
00:04:26,422 --> 00:04:31,161
Now, I'm going to use
this get method to just

62
00:04:31,161 --> 00:04:35,653
check to ensure that
the specific dish with

63
00:04:35,653 --> 00:04:40,292
a dishId is already a favorite for
the user.

64
00:04:40,292 --> 00:04:44,413
So instead of simply saying
GET operation not supported,

65
00:04:44,413 --> 00:04:48,879
I am just going to leverage
the presence of this get operation.

66
00:04:48,879 --> 00:04:52,574
And then we'll say,

67
00:04:52,574 --> 00:04:56,684
Favorites.findOne.

68
00:04:56,684 --> 00:04:59,843
And I will say,

69
00:04:59,843 --> 00:05:04,952
user: req.user.id.

70
00:05:04,952 --> 00:05:10,194
So we will find the favorites for
that particular user.

71
00:05:10,194 --> 00:05:20,166
And then we'll say, .then, favorites.

72
00:05:26,483 --> 00:05:32,913
And, catch((err),

73
00:05:35,757 --> 00:05:40,160
next(err)).

74
00:05:40,160 --> 00:05:45,638
And then similarly here,
we will add in the error here.

75
00:05:48,689 --> 00:05:50,239
Next(err)), here.

76
00:05:50,239 --> 00:05:55,689
So inside this .then,
when we get the favorites,

77
00:05:55,689 --> 00:06:00,290
then we will check, if (!favorites).

78
00:06:00,290 --> 00:06:04,500
So, if there are no favorites for
this user,

79
00:06:04,500 --> 00:06:08,770
then obviously the dish that we
are checking for doesn't exist.

80
00:06:08,770 --> 00:06:18,604
So we'll return, res.statusCode, 200.

81
00:06:22,232 --> 00:06:29,488
SetHeader( 'Content-Type

82
00:06:29,488 --> 00:06:34,436
' 'application/json').

83
00:06:34,436 --> 00:06:36,237
And then we'll return,

84
00:06:42,997 --> 00:06:51,490
Saying, "exists": false.

85
00:06:51,490 --> 00:06:56,891
So what we are specifying here
is that if the get is done

86
00:06:56,891 --> 00:07:02,771
to this endpoint with a dishId,
this exists flag here will

87
00:07:02,771 --> 00:07:07,826
be set to true if this dish
is part of my favorites.

88
00:07:07,826 --> 00:07:13,008
If this dish is not part of my favorites,
I will set the exists flag to false.

89
00:07:13,008 --> 00:07:16,687
So here, you see that since I
don't have any favorites, so

90
00:07:16,687 --> 00:07:20,008
exists should be automatically
false at this point.

91
00:07:20,008 --> 00:07:26,780
So we'll say "exists": false, and
then we will return the favorites, here.

92
00:07:28,950 --> 00:07:31,237
Well, obviously in this case,

93
00:07:31,237 --> 00:07:35,225
the favorites would be null at this point,
otherwise.

94
00:07:39,097 --> 00:07:42,779
So which means that favorites is not null,
so we'll say if,

95
00:07:45,218 --> 00:07:52,688
(favorites.dishes .indexOf),

96
00:07:52,688 --> 00:07:58,011
so we are going to be searching for
req.params.

97
00:08:00,046 --> 00:08:02,620
DishId, so we're going to search this.

98
00:08:02,620 --> 00:08:09,632
Favorites.dishes.array, to see
if does dish exists in there.

99
00:08:09,632 --> 00:08:15,410
And if it doesn't exist, obviously this
will return a negative index here.

100
00:08:15,410 --> 00:08:20,200
So in that case also,
I will return exactly the same as here.

101
00:08:20,200 --> 00:08:22,291
So if it returns a negative index,

102
00:08:22,291 --> 00:08:26,990
then that means that even though this
particular user has a center favorite.

103
00:08:26,990 --> 00:08:31,464
This specific dish doesn't
exist in the list his or

104
00:08:31,464 --> 00:08:36,987
her favorite, so
that's why it'll return exist false here.

105
00:08:36,987 --> 00:08:45,119
Now otherwise that means that the dish
exist in the list of favorite.

106
00:08:45,119 --> 00:08:51,352
So in this case, I will return
status code 200 exists is true.

107
00:08:51,352 --> 00:08:57,144
So that way when the user
performs a get operation on

108
00:08:57,144 --> 00:09:02,408
this end point with the /favorite/dishId.

109
00:09:02,408 --> 00:09:07,265
Where the dishId is supplied
as the parameter here.

110
00:09:07,265 --> 00:09:09,821
As the records parameter here,

111
00:09:09,821 --> 00:09:15,226
then we will check to see whether
that dish exists in the favorites.

112
00:09:15,226 --> 00:09:19,983
If none of the favorites exist for this
user then we'll return an exist false.

113
00:09:19,983 --> 00:09:22,138
Similarly, if the favorites exist,

114
00:09:22,138 --> 00:09:27,000
but that particular dish doesn't exist in
the favorites then it'll return a false.

115
00:09:27,000 --> 00:09:28,705
Otherwise it will return a true.

116
00:09:28,705 --> 00:09:33,890
So this exist flag can be
used by my client to check

117
00:09:33,890 --> 00:09:41,997
to see if this dish is part of the list
of favorite dishes for this user or not.

118
00:09:41,997 --> 00:09:48,624
Finally we'll update the users.js file.

119
00:09:48,624 --> 00:09:53,284
Now in the users.js file,
we need to add in

120
00:09:53,284 --> 00:09:58,204
another router.options field here because

121
00:09:58,204 --> 00:10:03,769
sometimes a Post request
as you saw with the login,

122
00:10:03,769 --> 00:10:10,760
we'll send the options first to check,
especially with cars,

123
00:10:10,760 --> 00:10:16,140
whether the post request will be allowed.

124
00:10:16,140 --> 00:10:23,156
So that's why they'll check cars,
cars with options here and then.

125
00:10:26,156 --> 00:10:27,915
We'll simply return

126
00:10:34,203 --> 00:10:39,938
A status message of 200
in response to that.

127
00:10:39,938 --> 00:10:44,624
So for
any endpoint under users if we received

128
00:10:44,624 --> 00:10:50,183
the options will simply
return a status 200 here.

129
00:10:50,183 --> 00:10:57,417
Now the Login function that
we had implemented earlier.

130
00:10:57,417 --> 00:11:02,782
We have simply done
passport.authenticate('local') here and

131
00:11:02,782 --> 00:11:06,600
then we check for
the remaining values here.

132
00:11:06,600 --> 00:11:11,006
Now this passport.authenticate('local'),
if the user doesn't get

133
00:11:11,006 --> 00:11:15,221
authenticated it simply returns
an unauthorized in the reply message.

134
00:11:15,221 --> 00:11:18,212
Now that may not be very meaningful for

135
00:11:18,212 --> 00:11:21,868
the client side to
display this information.

136
00:11:21,868 --> 00:11:27,245
So that is why we will enhance
this router post login method

137
00:11:27,245 --> 00:11:35,158
such that the authentication will return
more meaningful information at this part.

138
00:11:35,158 --> 00:11:39,831
So to do that,
we are not going to be doing the passport

139
00:11:39,831 --> 00:11:43,120
authenticate inside in here.

140
00:11:43,120 --> 00:11:47,180
Instead, we will take, so
let me remove that from there,

141
00:11:47,180 --> 00:11:52,410
and then you will see how I will
update the router post here.

142
00:11:52,410 --> 00:11:56,520
So we'll see carsWithOptions.

143
00:11:56,520 --> 00:12:03,806
And then we'll include the req,
res and next here.

144
00:12:03,806 --> 00:12:08,216
And inside the req, res, and

145
00:12:08,216 --> 00:12:14,227
next here, passport.authenticate,

146
00:12:17,271 --> 00:12:22,035
We'll call this with 'local'.

147
00:12:22,035 --> 00:12:27,041
Now when we call this with local,
if a authentication

148
00:12:27,041 --> 00:12:34,607
error occurs the passport.authenticate
can be made to return the error value,

149
00:12:34,607 --> 00:12:39,519
and also it'll return the user
if there is no error.

150
00:12:39,519 --> 00:12:42,283
And it could parameter called info,

151
00:12:42,283 --> 00:12:47,643
which will carry additional info that
might be passed back to the user.

152
00:12:47,643 --> 00:12:51,714
This error will be returned when there
is a genuine error that occurs in

153
00:12:51,714 --> 00:12:53,590
the possible to authenticate.

154
00:12:53,590 --> 00:12:58,995
But if the user information is sent
in to passport.authenticate but

155
00:12:58,995 --> 00:13:03,945
the user doesn't exist,
then that is not counted as an error.

156
00:13:03,945 --> 00:13:07,828
Instead, it will be counted
as user doesn't exist.

157
00:13:07,828 --> 00:13:12,825
And that information is passed back
in the info object that comes in.

158
00:13:12,825 --> 00:13:16,793
So the error will be returned when there
is a genuine error that occurs during

159
00:13:16,793 --> 00:13:18,405
the authentication process.

160
00:13:18,405 --> 00:13:23,995
But the info, they'll contain information
if the user doesn't exist and so

161
00:13:23,995 --> 00:13:30,102
the passport.authenticate is passing back
a message saying that the user doesn't

162
00:13:30,102 --> 00:13:35,780
exist or either the user name is
incorrect or the password is incorrect.

163
00:13:35,780 --> 00:13:40,415
And so on, so that information will
be passed in, in the info message.

164
00:13:40,415 --> 00:13:44,569
Now, we will see how this is useful to us
when we look at the client-side a little

165
00:13:44,569 --> 00:13:45,990
bit later.

166
00:13:45,990 --> 00:13:48,070
So in this situation,

167
00:13:49,530 --> 00:13:55,110
we will handle this as follows.

168
00:13:55,110 --> 00:14:00,510
And not only that,
when we call this passport authenticate,

169
00:14:00,510 --> 00:14:04,976
we also need to pass in a (req, res,

170
00:14:04,976 --> 00:14:08,550
next) as that three parameter strip.

171
00:14:08,550 --> 00:14:10,320
So this is the structure.

172
00:14:10,320 --> 00:14:13,558
When you need to call
passport authenticate,

173
00:14:13,558 --> 00:14:18,798
expect it to pass you back information
like this as a call back method here.

174
00:14:18,798 --> 00:14:24,072
So you also need to supply this req,
res next right there too.

175
00:14:24,072 --> 00:14:25,720
Now, if this occurs.

176
00:14:25,720 --> 00:14:30,206
So we'll say if (err).

177
00:14:30,206 --> 00:14:34,163
So if there's an error that occurs,

178
00:14:34,163 --> 00:14:39,781
we'll say return next (err) and
then let the error

179
00:14:39,781 --> 00:14:45,028
handler of our express
router take care of that.

180
00:14:45,028 --> 00:14:48,365
Now, we'll consider other situations.

181
00:14:48,365 --> 00:14:53,484
If(!user), so if we have reached
this point then that means that it

182
00:14:53,484 --> 00:14:59,232
was not an error that occurred but instead
perhaps the user could not be found.

183
00:14:59,232 --> 00:15:04,860
If the user is not found then the user
here will be set to null in this case.

184
00:15:04,860 --> 00:15:10,088
So, in that situation if
the user does not exist,

185
00:15:10,088 --> 00:15:17,068
then we need to be able to pass
information back to the server side.

186
00:15:17,068 --> 00:15:22,895
So what we will do is we will pass
in this information in this format,

187
00:15:22,895 --> 00:15:26,576
so I'm going to cut this out from here,
and

188
00:15:26,576 --> 00:15:30,491
then paste it in here and
then we will edit so.

189
00:15:30,491 --> 00:15:36,748
If the user is null,
then we will send back a statusCode

190
00:15:36,748 --> 00:15:41,509
of 401 which means unauthorized, and

191
00:15:41,509 --> 00:15:47,640
then we will send back
information success, false.

192
00:15:47,640 --> 00:15:54,340
And then we'll not be passing back the
token, we'll pass back the status message.

193
00:15:54,340 --> 00:16:02,501
So here we'll say login, Unsuccessful.

194
00:16:02,501 --> 00:16:07,870
And then the third information
will pass this info,

195
00:16:07,870 --> 00:16:13,238
that object that we received
here as the third part in

196
00:16:13,238 --> 00:16:19,231
that reply message that we send
back from our server here.

197
00:16:19,231 --> 00:16:22,496
So the success flag will reset to false.

198
00:16:22,496 --> 00:16:27,145
The status will be set Login Unsuccessful
and the error information,

199
00:16:27,145 --> 00:16:30,235
that is passed in the info
will be passed back.

200
00:16:30,235 --> 00:16:34,788
Now note that this situation will
occur if either the username and

201
00:16:34,788 --> 00:16:36,789
the password is incorrect.

202
00:16:36,789 --> 00:16:42,516
And so this is not an error, in the error
sense, but the fact that the authenticate

203
00:16:42,516 --> 00:16:47,505
could not find either the user or
the password of the user is incorrect.

204
00:16:47,505 --> 00:16:51,545
So that information will be encoded
into the inflow that comes in, and so

205
00:16:51,545 --> 00:16:58,227
that I will pass back as
an error to my client side.

206
00:16:58,227 --> 00:17:02,633
Otherwise part is

207
00:17:02,633 --> 00:17:08,810
handled as req.logIn.

208
00:17:08,810 --> 00:17:10,700
So if this is successful,

209
00:17:10,700 --> 00:17:16,200
the passport.authenticate will add this
method called req.logIn to the user.

210
00:17:16,200 --> 00:17:21,400
So at this point we will just pass in
the user object that we've obtained.

211
00:17:21,400 --> 00:17:26,398
So here, if we have reached this point,

212
00:17:26,398 --> 00:17:32,572
then that means that the user
object is not null and

213
00:17:32,572 --> 00:17:37,717
also no error occured, so that means that

214
00:17:37,717 --> 00:17:43,304
the user can be logged in and
so we wil say err.

215
00:17:43,304 --> 00:17:44,995
So it will try to login the user.

216
00:17:44,995 --> 00:17:47,231
So we'll say if err.

217
00:17:51,210 --> 00:17:58,260
And then we will pass back that same kind
of error information that we did here.

218
00:17:59,450 --> 00:18:02,317
So in this case, if the error.

219
00:18:06,077 --> 00:18:11,757
If error,
then we'll pass back status code 401 and

220
00:18:11,757 --> 00:18:18,970
we'll say success is false and
status is Login Unsuccessful.

221
00:18:18,970 --> 00:18:24,359
And then the error information

222
00:18:24,359 --> 00:18:29,539
we will pass this as instead of

223
00:18:29,539 --> 00:18:36,810
info we'll pass in could not log in user.

224
00:18:36,810 --> 00:18:42,580
So that is the message that will
pass back here, if the error occurs.

225
00:18:42,580 --> 00:18:46,195
Otherwise, we would be down below here.

226
00:18:46,195 --> 00:18:53,157
And so at this point we would
be able to generate the token.

227
00:18:53,157 --> 00:18:57,594
So if we have reached up to this
point that means that the user has

228
00:18:57,594 --> 00:19:01,892
successfully logged in and so
we can now generate the token.

229
00:19:01,892 --> 00:19:07,009
So we will generate the token
based upon the user ID and

230
00:19:07,009 --> 00:19:11,794
then we will pass back that
token back to the user.

231
00:19:11,794 --> 00:19:15,462
So here we will say var token.

232
00:19:15,462 --> 00:19:22,789
And then we can say res.statusCode = 200,
and then res.json(success) is true,

233
00:19:22,789 --> 00:19:26,999
which means that the user
successfully logged in.

234
00:19:26,999 --> 00:19:31,842
And so
the status would be Login Successful, and

235
00:19:31,842 --> 00:19:39,900
then the third part instead of the error
I will pass the token back to the user.

236
00:19:39,900 --> 00:19:45,590
So we'll say token, token,

237
00:19:45,590 --> 00:19:50,390
this token which we just obtained earlier,
so that to token will be passed in

238
00:19:50,390 --> 00:19:54,600
as the token property of
the rip light message.

239
00:19:54,600 --> 00:19:57,910
So here,
notice that this axis is set to true.

240
00:19:57,910 --> 00:20:01,890
So which means that the user
successfully logged in.

241
00:20:01,890 --> 00:20:05,660
And so the user can proceed
forward at this point.

242
00:20:05,660 --> 00:20:13,667
And this has to be done
inside the req.logIn here.

243
00:20:13,667 --> 00:20:20,640
So at this point we will
close the req.logIn.

244
00:20:20,640 --> 00:20:27,570
So notice that this is
inside this req.logIn here.

245
00:20:27,570 --> 00:20:30,830
So in there we will pass these three back.

246
00:20:30,830 --> 00:20:33,800
So let me just indent
threse three lines in.

247
00:20:35,830 --> 00:20:42,490
And so that is how we would
handle the users login.

248
00:20:42,490 --> 00:20:45,850
So again,
reviewing this code one more time.

249
00:20:45,850 --> 00:20:47,740
So we'll do router post, but

250
00:20:47,740 --> 00:20:52,490
instead of doing passport authenticate
right there, we will say req, res,

251
00:20:52,490 --> 00:20:57,970
next and then inside here we will do
a passport.authenticate for the local.

252
00:20:57,970 --> 00:21:02,930
And this authenticate will pass back, so
we can supply a callback function to that.

253
00:21:02,930 --> 00:21:06,810
And this callback function will
return either the error, the user, or

254
00:21:06,810 --> 00:21:08,370
the info here.

255
00:21:08,370 --> 00:21:13,220
And so, if it does an error we'll just
allow the express error handler to

256
00:21:13,220 --> 00:21:14,560
take care of that.

257
00:21:14,560 --> 00:21:20,580
If the user is null then that means
that the user logon was unsuccessful,

258
00:21:20,580 --> 00:21:25,090
and the reason for that will be in
the info so that will pass back as

259
00:21:25,090 --> 00:21:30,660
the info error in the plan message here.

260
00:21:30,660 --> 00:21:37,190
If we come up to this point then
the user is successfully verified.

261
00:21:37,190 --> 00:21:38,898
So then we will login the user.

262
00:21:38,898 --> 00:21:43,850
So the passport.authenticate will
add in this method called logIn to

263
00:21:43,850 --> 00:21:51,090
the request message, so
we can call the login with the user and

264
00:21:51,090 --> 00:21:56,760
if this returns an error, then we will
return the error here appropriately.

265
00:21:56,760 --> 00:22:01,400
If not then we would have reached
the point where the user is successfully

266
00:22:01,400 --> 00:22:06,560
authenticated so they can generate the
JSON web token here and return the JSON

267
00:22:06,560 --> 00:22:12,020
web token to the user to confirm that
the user is successfully logged.

268
00:22:12,020 --> 00:22:15,190
So that is the set of steps
that we're going to use here.

269
00:22:15,190 --> 00:22:19,910
Now the reason why I do a more elaborate
way of handling it is that I want to

270
00:22:19,910 --> 00:22:24,760
distinguish between the situation
where a genuine error occurs during

271
00:22:24,760 --> 00:22:30,700
the application process, as opposed to the
situation where the user name is invalid,

272
00:22:30,700 --> 00:22:32,830
or the password is invalid.

273
00:22:32,830 --> 00:22:37,713
So those two cases will be handled by
this situation where the info will

274
00:22:37,713 --> 00:22:40,129
carry the information back to us.

275
00:22:40,129 --> 00:22:44,551
So that's not an error perse but
that's a situation where

276
00:22:44,551 --> 00:22:49,440
the user is not a valid user or
the user's password is not valid.

277
00:22:49,440 --> 00:22:54,880
So that's how they will handle
the user's log in process.

278
00:22:54,880 --> 00:22:59,666
In addition,
I will add in one more method here called,

279
00:23:05,730 --> 00:23:08,832
checkJWToken.

280
00:23:08,832 --> 00:23:12,831
It is quite possible that while
the client has logged in and

281
00:23:12,831 --> 00:23:18,229
obtained the JSON web token, sometime
later, the JSON Web Token may expire.

282
00:23:18,229 --> 00:23:23,776
And so if the user tries to access from
the client side with an expired token

283
00:23:23,776 --> 00:23:29,159
to the server then the server will
not be able to authenticate the user.

284
00:23:29,159 --> 00:23:34,024
So at periodic intervals we may wish to
cross check to make sure that the JSON

285
00:23:34,024 --> 00:23:35,733
web token is still valid.

286
00:23:35,733 --> 00:23:41,180
So that is the reason why I am
including another endpoint called

287
00:23:41,180 --> 00:23:46,131
checkJWTToken, so
if you do a get to the checkJWTToken.

288
00:23:46,131 --> 00:23:50,927
By including the token into
the authorization header,

289
00:23:50,927 --> 00:23:55,926
then this call will return a true or
false to indicate to you

290
00:23:55,926 --> 00:24:00,125
whether the JSON web token
is still valid or not.

291
00:24:00,125 --> 00:24:04,430
If it is not valid then the client side
can initiate another login for For

292
00:24:04,430 --> 00:24:09,710
the user to obtain a new JSON web token,
if required.

293
00:24:09,710 --> 00:24:15,470
So to do this, we'll say cors,
corsWithOptions and,

294
00:24:19,500 --> 00:24:23,760
req, res, here, as expected.

295
00:24:25,510 --> 00:24:28,029
And in here we'll say,

296
00:24:31,852 --> 00:24:40,983
passport.authenticate('jwt',

297
00:24:42,356 --> 00:24:49,886
And, {session: false}).

298
00:24:54,050 --> 00:24:59,322
And this would return err, user, info.

299
00:25:03,010 --> 00:25:07,005
So recall how we used the Passport
authenticator earlier.

300
00:25:07,005 --> 00:25:11,050
So the JWT session falls here.

301
00:25:11,050 --> 00:25:14,759
So earlier here we say,
passport.authenticate local.

302
00:25:14,759 --> 00:25:17,039
So this is for the local authentication.

303
00:25:17,039 --> 00:25:21,038
So this is for
the JSON web token authentication.

304
00:25:21,038 --> 00:25:26,303
So when we call that, then, since that
is going to verify the JSON web token,

305
00:25:26,303 --> 00:25:33,820
so I'm going to say,
if (err), return next(err).

306
00:25:33,820 --> 00:25:38,540
And then let the Express error
handler take care of that situation.

307
00:25:38,540 --> 00:25:42,895
And then we'll say, if (!user),

308
00:25:47,340 --> 00:25:53,395
If the user doesn't exist,
then similarly, else.

309
00:25:53,395 --> 00:25:58,850
So which means that if the user object
was found from the JSON web token and

310
00:25:58,850 --> 00:26:04,764
then loaded onto the req.user, then that
means that the user is a valid user.

311
00:26:04,764 --> 00:26:06,990
And so can be allowed to proceed forward.

312
00:26:06,990 --> 00:26:13,770
Otherwise, we're going to say
that the user doesn't exist.

313
00:26:13,770 --> 00:26:18,480
So we need to infer that
the JSON web token has expired.

314
00:26:18,480 --> 00:26:24,495
So at this point,
we'll send a res with the status code of,

315
00:26:29,070 --> 00:26:31,580
401, so unauthorized.

316
00:26:33,847 --> 00:26:40,570
SetHeader(, 'Content-Type',

317
00:26:42,865 --> 00:26:45,940
'application/json').

318
00:26:45,940 --> 00:26:52,243
And then we'll return res,

319
00:26:54,894 --> 00:27:00,970
.json, we'll say, {status:,

320
00:27:04,165 --> 00:27:07,131
'JWT invalid!'.

321
00:27:07,131 --> 00:27:15,242
And then We'll return a flag
called success: false.

322
00:27:15,242 --> 00:27:20,624
And then, We'll return the info that we

323
00:27:20,624 --> 00:27:26,890
obtain if the user is not authenticated
as the error at this point.

324
00:27:30,450 --> 00:27:36,219
Otherwise, that means that we reach this
point when the user is a valid user.

325
00:27:36,219 --> 00:27:40,921
So in this case,
let me just copy that code here,

326
00:27:40,921 --> 00:27:45,392
we'll be sending a status code of 200, and

327
00:27:45,392 --> 00:27:48,727
then the res.json will send JWT,

328
00:27:51,140 --> 00:27:55,050
valid!, and success will be true.

329
00:27:56,550 --> 00:28:03,290
And the third part,
we will send the user's information.

330
00:28:03,290 --> 00:28:07,776
So that way, when this endpoint is called

331
00:28:07,776 --> 00:28:12,710
with the get method, then this will
verify whether the token is valid or not.

332
00:28:12,710 --> 00:28:15,580
If the token is valid,
then you will receive this reply.

333
00:28:15,580 --> 00:28:17,311
And from the success flag in the reply,

334
00:28:17,311 --> 00:28:20,050
you can check to see whether
the JSON web token is valid or not.

335
00:28:20,050 --> 00:28:24,010
And this is useful on the client-side.

336
00:28:24,010 --> 00:28:30,012
Now this passport here,
passport.authenticate here,

337
00:28:30,012 --> 00:28:37,720
will have to be supplied with req and
res as the two parameters here.

338
00:28:37,720 --> 00:28:41,320
So that's how we call that
passport.authenticate.

339
00:28:41,320 --> 00:28:45,060
Notice that whenever you call
passport.authenticate and

340
00:28:45,060 --> 00:28:49,917
expect this callback function in here,
you need to append this point, req,

341
00:28:49,917 --> 00:28:53,973
.res, to that passport.authenticate,
and then back here.

342
00:28:53,973 --> 00:28:57,915
So with this, we have updated
everything on the server-side.

343
00:28:57,915 --> 00:29:01,900
So let's save all the changes
on the server-side.

344
00:29:01,900 --> 00:29:05,400
So now our server is all ready to

345
00:29:05,400 --> 00:29:10,680
handle the incoming requests
from our Angular client.

346
00:29:10,680 --> 00:29:13,120
With this, we complete this exercise.

347
00:29:13,120 --> 00:29:18,010
In this exercise,
we have now prepared our Express server to

348
00:29:18,010 --> 00:29:22,930
handle incoming requests
from our Angular client.

349
00:29:22,930 --> 00:29:26,890
In the next exercise, we're going to look
at the Angular client in more detail to

350
00:29:26,890 --> 00:29:32,350
understand how it is communicating
with this extra server.

351
00:29:32,350 --> 00:29:37,881
This is a good time for
you to do a Git commit with the message,

352
00:29:37,881 --> 00:29:40,932
integrating client and server.

353
00:29:40,932 --> 00:29:44,825
[MUSIC]