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

2
00:00:04,614 --> 00:00:09,792
Мы уже разработали полноценный API-сервер REST с использованием Express и

3
00:00:09,792 --> 00:00:12,026
MongoDB в рамках этого курса.

4
00:00:12,026 --> 00:00:16,881
Для того, чтобы сервер имел возможность полноценно общаться с нашим клиентом,

5
00:00:16,881 --> 00:00:21,892
мы внесем в него несколько незначительных корректировок, чтобы он возвращал правильные данные.

6
00:00:21,892 --> 00:00:26,063
Чтобы наша клиентская реализация могла более эффективно работать

7
00:00:26,063 --> 00:00:29,370
с данными, возвращаемыми с нашего сервера.

8
00:00:29,370 --> 00:00:30,427
Поэтому, чтобы сделать это,

9
00:00:30,427 --> 00:00:35,724
давайте поработаем над несколькими корректировками на нашей серверной стороне в этом упражнении.

10
00:00:37,478 --> 00:00:43,220
Перейдя на наш сервер в редакторе, прежде чем мы начнем работать на сервере,

11
00:00:43,220 --> 00:00:48,497
я бы предложил вам скачать все изображения, которые я предоставил в

12
00:00:48,497 --> 00:00:53,260
виде zip-файла в ресурсах упражнения под названием images.zip.

13
00:00:53,260 --> 00:00:56,530
Разархивируйте файл, а затем получите все изображения оттуда, а

14
00:00:56,530 --> 00:01:03,440
затем скопируйте эти изображения в общедоступную папку изображений на нашем сервере.

15
00:01:03,440 --> 00:01:08,980
Таким образом, вы видите, что здесь я скопировал все изображения в мою общую

16
00:01:08,980 --> 00:01:10,580
папку изображений здесь уже.

17
00:01:10,580 --> 00:01:15,120
Потому что наш сервер - это тот, который будет обслуживать все эти изображения для

18
00:01:15,120 --> 00:01:17,460
нашего клиентского приложения.

19
00:01:17,460 --> 00:01:22,820
Затем мы перейдем к корсам и подстроим этот белый список.

20
00:01:22,820 --> 00:01:27,919
Поэтому для нашего углового клиентского приложения, если мы запустим его

21
00:01:27,919 --> 00:01:33,571
с помощью команды ng serve, он работает на локальном хосте: 4200.

22
00:01:33,571 --> 00:01:36,196
Таким образом, любые запросы, поступающие из нашего углового

23
00:01:36,196 --> 00:01:40,750
приложения на сервер, будут нести это как их происхождение там.

24
00:01:40,750 --> 00:01:44,710
Вот почему я собираюсь добавить это в свой белый список,

25
00:01:44,710 --> 00:01:50,310
чтобы любые проблемы cors были решены автоматически.

26
00:01:50,310 --> 00:01:54,848
Поэтому, перейдя

27
00:01:54,848 --> 00:01:59,698
в этот файл cors.js, в моем белом списке, позвольте мне добавить

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

29
00:02:08,371 --> 00:02:12,503
И это источник, из которого все мои Angular клиент будет

30
00:02:12,503 --> 00:02:16,690
исходить запрос, который приходит на этот сервер.

31
00:02:16,690 --> 00:02:22,020
Таким образом, мои cors не вызовут проблем для клиента Angular.

32
00:02:22,020 --> 00:02:27,760
Далее нужно обновить несколько маршрутов для обработки

33
00:02:27,760 --> 00:02:32,760
параметров запроса, а также несколько незначительных других корректировок.

34
00:02:32,760 --> 00:02:35,905
Позвольте мне начать с файлов promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
Так что это просто обновить.

36
00:02:39,760 --> 00:02:44,790
Поэтому, перейдя в файл promoRouter.js, в файле Promorouter, для

37
00:02:44,790 --> 00:02:47,960
запроса получения, который мы получаем здесь,

38
00:02:47,960 --> 00:02:52,400
вместо того, чтобы делать promotions.Find с пустым JavaScript,

39
00:02:52,400 --> 00:02:57,256
здесь я бы предоставил req.query

40
00:02:57,256 --> 00:03:02,470
в качестве параметра для этого promotions.Find здесь.

41
00:03:02,470 --> 00:03:07,650
То же самое и с LeaderRouter, поэтому позвольте мне перейти к файлу leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
И в LeaderRouter также,

43
00:03:09,786 --> 00:03:14,642
здесь, где вы найдете leaders.Find с пустым объектом JavaScript.

44
00:03:14,642 --> 00:03:18,423
Вместо этого замените это на этот

45
00:03:18,423 --> 00:03:21,852
req.query, чтобы параметры запроса были переданы.

46
00:03:21,852 --> 00:03:26,430
Таким образом, это то, где мы будем передавать в Рекомендуемом столбце

47
00:03:26,430 --> 00:03:29,487
через как параметр запроса.

48
00:03:29,487 --> 00:03:34,678
Теперь, скорректировав эти два, давайте теперь поработаем над маршрутом блюда,

49
00:03:34,678 --> 00:03:41,090
поэтому перейдя в файл dishRouter.js, даже в DishRouter, то же обновление здесь.

50
00:03:41,090 --> 00:03:48,920
Итак, перейдя к этим блюдам.Find в методе get здесь, измените это на req.query.

51
00:03:48,920 --> 00:03:52,987
Таким образом, мое обновление DishRouter было завершено.

52
00:03:52,987 --> 00:03:57,664
Таким образом, мы теперь обновили PromorOuter, ReaderRouter и

53
00:03:57,664 --> 00:04:02,784
DishRouter, то мы перейдем к обновлению этого FavoriterOuter.

54
00:04:02,784 --> 00:04:07,519
Теперь вы бы реализовали любимый маршрутизатор как часть вашего

55
00:04:07,519 --> 00:04:09,500
четвертого задания.

56
00:04:09,500 --> 00:04:12,306
Теперь в FavoriterOuter вы увидите, что для

57
00:04:12,306 --> 00:04:16,618
FavoriterOuter я не показываю вам оставшийся партер, потому что

58
00:04:16,618 --> 00:04:19,437
вы должны были сделать как часть вашего задания.

59
00:04:19,437 --> 00:04:22,925
Позвольте мне сначала обратить ваше внимание на метод get для

60
00:04:22,925 --> 00:04:26,422
Favoriterouter.route («/:dishid').

61
00:04:26,422 --> 00:04:31,161
Теперь я собираюсь использовать этот метод get,

62
00:04:31,161 --> 00:04:35,653
чтобы просто проверить, что конкретное блюдо с

63
00:04:35,653 --> 00:04:40,292
DishID уже является любимым для пользователя.

64
00:04:40,292 --> 00:04:44,413
Поэтому вместо того, чтобы просто сказать, что операция GET не поддерживается,

65
00:04:44,413 --> 00:04:48,879
я просто собираюсь использовать наличие этой операции get.

66
00:04:48,879 --> 00:04:52,574
А потом мы скажем, «

67
00:04:52,574 --> 00:04:56,684
Избранные».

68
00:04:56,684 --> 00:04:59,843
И я скажу,

69
00:04:59,843 --> 00:05:04,952
пользователь: req.user.id,

70
00:05:04,952 --> 00:05:10,194
поэтому мы найдем избранное для этого конкретного пользователя.

71
00:05:10,194 --> 00:05:20,166
А потом мы скажем, «Фавориты».

72
00:05:26,483 --> 00:05:32,913
И, поймать (((err),

73
00:05:35,757 --> 00:05:40,160
следующий (err)).

74
00:05:40,160 --> 00:05:45,638
И тогда аналогичным образом здесь, мы добавим в ошибку здесь.

75
00:05:48,689 --> 00:05:50,239
Далее (err)), вот.

76
00:05:50,239 --> 00:05:55,689
Так что внутри это.then, когда мы получим избранное,

77
00:05:55,689 --> 00:06:00,290
то мы проверим, если (! избранное).

78
00:06:00,290 --> 00:06:04,500
Итак, если нет фаворитов для этого пользователя,

79
00:06:04,500 --> 00:06:08,770
то, очевидно, блюдо, которое мы проверяем, не существует.

80
00:06:08,770 --> 00:06:18,604
Так что мы вернёмся, Res.StatusCode, 200.

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

82
00:06:29,488 --> 00:06:34,436
'' приложение/json ').

83
00:06:34,436 --> 00:06:36,237
И тогда мы вернемся,

84
00:06:42,997 --> 00:06:51,490
говоря, «существует»: ложь.

85
00:06:51,490 --> 00:06:56,891
Итак, что мы указываем здесь, это то, что если get делается

86
00:06:56,891 --> 00:07:02,771
на эту конечную точку с помощью DishID, этот флаг существует здесь

87
00:07:02,771 --> 00:07:07,826
будет установлен в true, если это блюдо является частью моего избранного.

88
00:07:07,826 --> 00:07:13,008
Если это блюдо не является частью моего избранного, я установлю флаг exists на false.

89
00:07:13,008 --> 00:07:16,687
Итак, здесь вы видите, что, поскольку у меня нет фаворитов, поэтому

90
00:07:16,687 --> 00:07:20,008
существует должен быть автоматически ложным на данный момент.

91
00:07:20,008 --> 00:07:26,780
Так что мы скажем «существует»: false, и тогда мы вернем избранное, здесь.

92
00:07:28,950 --> 00:07:31,237
Ну, очевидно, в этом случае

93
00:07:31,237 --> 00:07:35,225
фавориты будут нулевыми в данный момент, в противном случае.

94
00:07:39,097 --> 00:07:42,779
Таким образом, это означает, что избранное не является нулевым, поэтому мы скажем, если,

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

96
00:07:52,688 --> 00:07:58,011
поэтому мы будем искать req.params.

97
00:08:00,046 --> 00:08:02,620
Дишид, так что мы собираемся обыскать это.

98
00:08:02,620 --> 00:08:09,632
Favorites.Dishes.Array, чтобы увидеть, существует ли блюдо там.

99
00:08:09,632 --> 00:08:15,410
И если его не существует, очевидно, это вернет отрицательный индекс здесь.

100
00:08:15,410 --> 00:08:20,200
Так что в этом случае я вернусь точно так же, как и здесь.

101
00:08:20,200 --> 00:08:22,291
Поэтому, если он возвращает отрицательный индекс,

102
00:08:22,291 --> 00:08:26,990
то это означает, что даже если у этого конкретного пользователя есть фаворит центра.

103
00:08:26,990 --> 00:08:31,464
Это конкретное блюдо не существует в списке его или

104
00:08:31,464 --> 00:08:36,987
ее любимого, поэтому он вернется существует false здесь.

105
00:08:36,987 --> 00:08:45,119
Теперь в противном случае это означает, что блюдо существует в списке любимых.

106
00:08:45,119 --> 00:08:51,352
Таким образом, в этом случае я верну код состояния 200 существует.

107
00:08:51,352 --> 00:08:57,144
Таким образом, когда пользователь выполняет операцию get в

108
00:08:57,144 --> 00:09:02,408
этой конечной точке с помощью /favorite/dishid.

109
00:09:02,408 --> 00:09:07,265
Там, где в качестве параметра указан DishID.

110
00:09:07,265 --> 00:09:09,821
В качестве параметра записей здесь,

111
00:09:09,821 --> 00:09:15,226
то мы проверим, существует ли это блюдо в избранном.

112
00:09:15,226 --> 00:09:19,983
Если ни один из фаворитов не существует для этого пользователя, то мы вернем существующее false.

113
00:09:19,983 --> 00:09:22,138
Аналогично, если фавориты существуют,

114
00:09:22,138 --> 00:09:27,000
но это конкретное блюдо не существует в избранном, то оно вернет ложное.

115
00:09:27,000 --> 00:09:28,705
В противном случае он вернет истину.

116
00:09:28,705 --> 00:09:33,890
Таким образом, этот флаг существует может быть использован моим клиентом,

117
00:09:33,890 --> 00:09:41,997
чтобы проверить, является ли это блюдо частью списка любимых блюд для этого пользователя или нет.

118
00:09:41,997 --> 00:09:48,624
Наконец, мы обновим файл users.js.

119
00:09:48,624 --> 00:09:53,284
Теперь в файле users.js, нам нужно добавить в

120
00:09:53,284 --> 00:09:58,204
другое поле router.options здесь, потому что

121
00:09:58,204 --> 00:10:03,769
иногда Post запрос, как вы видели с логином,

122
00:10:03,769 --> 00:10:10,760
мы отправим параметры сначала проверить, особенно с автомобилями,

123
00:10:10,760 --> 00:10:16,140
будет ли почтовый запрос разрешен.

124
00:10:16,140 --> 00:10:23,156
Вот почему они проверяют машины, машины с опциями здесь и потом.

125
00:10:26,156 --> 00:10:27,915
Мы просто вернем

126
00:10:34,203 --> 00:10:39,938
сообщение о состоянии 200 в ответ на это.

127
00:10:39,938 --> 00:10:44,624
Таким образом, для любой конечной точки под пользователями, если мы получили

128
00:10:44,624 --> 00:10:50,183
параметры просто вернет статус 200 здесь.

129
00:10:50,183 --> 00:10:57,417
Теперь функция Login, которую мы реализовали ранее.

130
00:10:57,417 --> 00:11:02,782
Мы просто сделали pasport.authenticate («локальный») здесь, а

131
00:11:02,782 --> 00:11:06,600
затем мы проверяем остальные значения здесь.

132
00:11:06,600 --> 00:11:11,006
Теперь этот passport.authenticate ('local'), если пользователь не

133
00:11:11,006 --> 00:11:15,221
проходит проверку подлинности, он просто возвращает несанкционированный в ответном сообщении.

134
00:11:15,221 --> 00:11:18,212
Теперь это может быть не очень значимым для

135
00:11:18,212 --> 00:11:21,868
клиентской стороны, чтобы отобразить эту информацию.

136
00:11:21,868 --> 00:11:27,245
Поэтому мы усовершенствуем этот метод входа в систему маршрутизатора

137
00:11:27,245 --> 00:11:35,158
таким образом, что аутентификация будет возвращать более значимую информацию в этой части.

138
00:11:35,158 --> 00:11:39,831
Чтобы сделать это, мы не собираемся делать паспорт,

139
00:11:39,831 --> 00:11:43,120
удостоверяющий личность внутри здесь.

140
00:11:43,120 --> 00:11:47,180
Вместо этого мы возьмем, поэтому позвольте мне удалить это оттуда,

141
00:11:47,180 --> 00:11:52,410
и тогда вы увидите, как я буду обновлять сообщение маршрутизатора здесь.

142
00:11:52,410 --> 00:11:56,520
Итак, мы увидим автомобилиWithOptions.

143
00:11:56,520 --> 00:12:03,806
А потом мы включим рек, рез и следующий здесь.

144
00:12:03,806 --> 00:12:08,216
И внутри req, res, и

145
00:12:08,216 --> 00:12:14,227
следующий здесь, passport.authenticate,

146
00:12:17,271 --> 00:12:22,035
Мы назовем это с «локальным».

147
00:12:22,035 --> 00:12:27,041
Теперь, когда мы вызываем это с локальным, если

148
00:12:27,041 --> 00:12:34,607
возникает ошибка аутентификации, passport.authenticate может быть сделан, чтобы

149
00:12:34,607 --> 00:12:39,519
вернуть значение ошибки, а также он вернет пользователя, если нет ошибки.

150
00:12:39,519 --> 00:12:42,283
И это может быть параметр, называемый info,

151
00:12:42,283 --> 00:12:47,643
который будет нести дополнительную информацию, которая может быть передана обратно пользователю.

152
00:12:47,643 --> 00:12:51,714
Эта ошибка будет возвращена, когда есть подлинная ошибка, которая возникает

153
00:12:51,714 --> 00:12:53,590
в возможности для проверки подлинности.

154
00:12:53,590 --> 00:12:58,995
Но если информация пользователя отправляется в passport.authenticate, но

155
00:12:58,995 --> 00:13:03,945
пользователь не существует, то это не считается ошибкой.

156
00:13:03,945 --> 00:13:07,828
Вместо этого он будет считаться, как пользователь не существует.

157
00:13:07,828 --> 00:13:12,825
И эта информация передается обратно в инфообъект, который входит.

158
00:13:12,825 --> 00:13:16,793
Таким образом, ошибка будет возвращена, когда есть подлинная ошибка, которая возникает во время

159
00:13:16,793 --> 00:13:18,405
процесса проверки подлинности.

160
00:13:18,405 --> 00:13:23,995
Но информация, они будут содержать информацию, если пользователь не существует, и поэтому

161
00:13:23,995 --> 00:13:30,102
passport.authenticate передает обратно сообщение о том, что пользователь не

162
00:13:30,102 --> 00:13:35,780
существует или либо имя пользователя неправильное, либо пароль неверный.

163
00:13:35,780 --> 00:13:40,415
И так далее, чтобы информация была передана в информационном сообщении.

164
00:13:40,415 --> 00:13:44,569
Теперь мы увидим, как это полезно для нас, когда посмотрим на клиентскую сторону

165
00:13:44,569 --> 00:13:45,990
немного позже.

166
00:13:45,990 --> 00:13:48,070
Таким образом, в этой ситуации

167
00:13:49,530 --> 00:13:55,110
мы будем обрабатывать это следующим образом.

168
00:13:55,110 --> 00:14:00,510
И не только это, когда мы называем этот паспорт аутентифицировать,

169
00:14:00,510 --> 00:14:04,976
нам также нужно передать в (req, res,

170
00:14:04,976 --> 00:14:08,550
next), как это три параметра полосы.

171
00:14:08,550 --> 00:14:10,320
Так вот структура.

172
00:14:10,320 --> 00:14:13,558
Когда вам нужно вызвать аутентификацию паспорта,

173
00:14:13,558 --> 00:14:18,798
ожидайте, что он передаст вам такую информацию в качестве метода обратного вызова здесь.

174
00:14:18,798 --> 00:14:24,072
Таким образом, вам также нужно предоставить этот req, res следующий прямо там тоже.

175
00:14:24,072 --> 00:14:25,720
Теперь, если это произойдет.

176
00:14:25,720 --> 00:14:30,206
Так что мы скажем, если (err).

177
00:14:30,206 --> 00:14:34,163
Поэтому, если возникает ошибка,

178
00:14:34,163 --> 00:14:39,781
мы скажем, return next (err), а затем пусть

179
00:14:39,781 --> 00:14:45,028
обработчик ошибок нашего экспресс-маршрутизатора позаботится об этом.

180
00:14:45,028 --> 00:14:48,365
Теперь рассмотрим другие ситуации.

181
00:14:48,365 --> 00:14:53,484
Если (! ), поэтому если мы достигли этой точки, то это означает, что это

182
00:14:53,484 --> 00:14:59,232
не ошибка, которая произошла, но вместо этого, возможно, пользователь не может быть найден.

183
00:14:59,232 --> 00:15:04,860
Если пользователь не найден, то пользователь здесь будет установлен в null в этом случае.

184
00:15:04,860 --> 00:15:10,088
Таким образом, в такой ситуации, если пользователь не существует,

185
00:15:10,088 --> 00:15:17,068
то нам нужно иметь возможность передавать информацию обратно на сторону сервера.

186
00:15:17,068 --> 00:15:22,895
Итак, что мы будем делать, это мы передадим эту информацию в этом формате,

187
00:15:22,895 --> 00:15:26,576
так что я собираюсь вырезать это отсюда, а

188
00:15:26,576 --> 00:15:30,491
затем вставить его сюда, а затем мы будем редактировать так.

189
00:15:30,491 --> 00:15:36,748
Если пользователь равен нулю, то мы отправим обратно statusCode

190
00:15:36,748 --> 00:15:41,509
401, что означает несанкционированный, а

191
00:15:41,509 --> 00:15:47,640
затем мы отправим обратно информацию об успехе, false.

192
00:15:47,640 --> 00:15:54,340
И тогда мы не будем передавать токен назад, мы передадим сообщение о состоянии.

193
00:15:54,340 --> 00:16:02,501
Итак, здесь мы скажем логин, Неудачный.

194
00:16:02,501 --> 00:16:07,870
И тогда третья информация передаст эту информацию, этот

195
00:16:07,870 --> 00:16:13,238
объект, который мы получили здесь в качестве третьей части

196
00:16:13,238 --> 00:16:19,231
этого ответного сообщения, которое мы отправляем обратно с нашего сервера здесь.

197
00:16:19,231 --> 00:16:22,496
Таким образом, флаг успеха будет сброшен на false.

198
00:16:22,496 --> 00:16:27,145
Статус будет установлен Login Unscessed и информация об ошибке,

199
00:16:27,145 --> 00:16:30,235
которая передается в информации, будет передана обратно.

200
00:16:30,235 --> 00:16:34,788
Теперь обратите внимание, что эта ситуация произойдет, если либо имя пользователя и

201
00:16:34,788 --> 00:16:36,789
пароль неверны.

202
00:16:36,789 --> 00:16:42,516
И поэтому это не ошибка, в смысле ошибки, но тот факт, что аутентификация

203
00:16:42,516 --> 00:16:47,505
не смогла найти ни пользователя, ни пароля пользователя, является неправильным.

204
00:16:47,505 --> 00:16:51,545
Таким образом, информация будет закодирована в притоке, который приходит, и так,

205
00:16:51,545 --> 00:16:58,227
что я передам обратно как ошибку на мою клиентскую сторону.

206
00:16:58,227 --> 00:17:02,633
В противном случае часть

207
00:17:02,633 --> 00:17:08,810
обрабатывается как req.login.

208
00:17:08,810 --> 00:17:10,700
Поэтому, если это успешно,

209
00:17:10,700 --> 00:17:16,200
passport.authenticate добавит к пользователю этот метод req.login.

210
00:17:16,200 --> 00:17:21,400
Таким образом, в этот момент мы просто передадим в объект пользователя, который мы получили.

211
00:17:21,400 --> 00:17:26,398
Итак, если мы достигли этой точки,

212
00:17:26,398 --> 00:17:32,572
то это означает, что объект пользователя не является нулевым, а

213
00:17:32,572 --> 00:17:37,717
также не произошла ошибка, так что это означает, что

214
00:17:37,717 --> 00:17:43,304
пользователь может войти в систему, и поэтому мы будем говорить err.

215
00:17:43,304 --> 00:17:44,995
Таким образом, он попытается войти в систему пользователя.

216
00:17:44,995 --> 00:17:47,231
Так что скажем, если ошибаешься.

217
00:17:51,210 --> 00:17:58,260
И тогда мы передадим обратно ту же информацию об ошибках, что мы сделали здесь.

218
00:17:59,450 --> 00:18:02,317
Поэтому в этом случае, если ошибка.

219
00:18:06,077 --> 00:18:11,757
Если ошибка, то мы передадим код состояния 401, и

220
00:18:11,757 --> 00:18:18,970
мы скажем, успех ложный, а статус - Вход Неудачный.

221
00:18:18,970 --> 00:18:24,359
И тогда информация об ошибке, которую

222
00:18:24,359 --> 00:18:29,539
мы передадим, так как вместо

223
00:18:29,539 --> 00:18:36,810
информации, которую мы передадим, не может войти в систему пользователя.

224
00:18:36,810 --> 00:18:42,580
Таким образом, это сообщение, которое будет передаваться здесь, если произойдет ошибка.

225
00:18:42,580 --> 00:18:46,195
В противном случае, мы были бы внизу.

226
00:18:46,195 --> 00:18:53,157
И поэтому в этот момент мы сможем сгенерировать токен.

227
00:18:53,157 --> 00:18:57,594
Поэтому, если мы достигли этого момента, это означает, что пользователь

228
00:18:57,594 --> 00:19:01,892
успешно вошел в систему, и поэтому теперь мы можем сгенерировать токен.

229
00:19:01,892 --> 00:19:07,009
Таким образом, мы будем генерировать токен на основе идентификатора пользователя, а

230
00:19:07,009 --> 00:19:11,794
затем мы передадим этот токен обратно пользователю.

231
00:19:11,794 --> 00:19:15,462
Итак, здесь мы скажем токен var.

232
00:19:15,462 --> 00:19:22,789
И тогда мы можем сказать res.statusCode = 200, а затем res.json (успех) верно,

233
00:19:22,789 --> 00:19:26,999
что означает, что пользователь успешно вошел в систему.

234
00:19:26,999 --> 00:19:31,842
И поэтому статус будет логин успешно, а

235
00:19:31,842 --> 00:19:39,900
затем третья часть вместо ошибки я передам токен обратно пользователю.

236
00:19:39,900 --> 00:19:45,590
Итак, мы скажем токен, токен,

237
00:19:45,590 --> 00:19:50,390
этот токен, который мы только что получили ранее, так что токен будет передан

238
00:19:50,390 --> 00:19:54,600
в качестве свойства токена сообщения rip light.

239
00:19:54,600 --> 00:19:57,910
Итак, обратите внимание, что эта ось установлена в true.

240
00:19:57,910 --> 00:20:01,890
Таким образом, это означает, что пользователь успешно вошел в систему.

241
00:20:01,890 --> 00:20:05,660
И поэтому пользователь может продолжить движение вперед на этом этапе.

242
00:20:05,660 --> 00:20:13,667
И это должно быть сделано внутри req.Login здесь.

243
00:20:13,667 --> 00:20:20,640
Таким образом, в этот момент мы закроем req.Login.

244
00:20:20,640 --> 00:20:27,570
Поэтому обратите внимание, что это внутри этого req.Login здесь.

245
00:20:27,570 --> 00:20:30,830
Так что там мы передадим этих троих назад.

246
00:20:30,830 --> 00:20:33,800
Поэтому позвольте мне просто отстукнуть порог трех строк в.

247
00:20:35,830 --> 00:20:42,490
И так мы будем обрабатывать логин пользователей.

248
00:20:42,490 --> 00:20:45,850
Опять же, просмотрев этот код еще раз.

249
00:20:45,850 --> 00:20:47,740
Таким образом, мы сделаем сообщение маршрутизатора, но

250
00:20:47,740 --> 00:20:52,490
вместо того, чтобы аутентифицировать паспорт прямо там, мы скажем req, res,

251
00:20:52,490 --> 00:20:57,970
next, а затем внутри здесь мы сделаем паспорт.authenticate для локального.

252
00:20:57,970 --> 00:21:02,930
И эта аутентификация будет передана обратно, поэтому мы можем предоставить функцию обратного вызова для этого.

253
00:21:02,930 --> 00:21:06,810
И эта функция обратного вызова вернет либо ошибку, пользователя, либо

254
00:21:06,810 --> 00:21:08,370
информацию здесь.

255
00:21:08,370 --> 00:21:13,220
И поэтому, если он делает ошибку, мы просто позволим обработчику экспресс-ошибок

256
00:21:13,220 --> 00:21:14,560
позаботиться об этом.

257
00:21:14,560 --> 00:21:20,580
Если пользователь имеет значение null, то это означает, что вход пользователя был неудачным,

258
00:21:20,580 --> 00:21:25,090
и причина этого будет в информации, чтобы вернуться в качестве

259
00:21:25,090 --> 00:21:30,660
информационной ошибки в сообщении плана здесь.

260
00:21:30,660 --> 00:21:37,190
Если мы подойдем к этому моменту, то пользователь успешно проверен.

261
00:21:37,190 --> 00:21:38,898
Таким образом, мы войдем в систему пользователя.

262
00:21:38,898 --> 00:21:43,850
Таким образом, passport.authenticate добавит в этот метод под названием Login в

263
00:21:43,850 --> 00:21:51,090
сообщение запроса, поэтому мы можем вызвать логин с пользователем, и

264
00:21:51,090 --> 00:21:56,760
если это возвращает ошибку, то мы вернем ошибку здесь соответствующим образом.

265
00:21:56,760 --> 00:22:01,400
Если нет, то мы достигли бы точки, где пользователь успешно

266
00:22:01,400 --> 00:22:06,560
аутентифицирован, поэтому они могут генерировать веб-токен JSON здесь и вернуть

267
00:22:06,560 --> 00:22:12,020
веб-токен JSON пользователю, чтобы подтвердить, что пользователь успешно вошел в систему.

268
00:22:12,020 --> 00:22:15,190
Так что это набор шагов, которые мы будем использовать здесь.

269
00:22:15,190 --> 00:22:19,910
Теперь причина, по которой я делаю более сложный способ обработки, заключается в том, что я хочу

270
00:22:19,910 --> 00:22:24,760
различать ситуацию, когда происходит подлинная ошибка во время

271
00:22:24,760 --> 00:22:30,700
процесса приложения, в отличие от ситуации, когда имя пользователя недействительно

272
00:22:30,700 --> 00:22:32,830
или пароль недействителен.

273
00:22:32,830 --> 00:22:37,713
Таким образом, эти два случая будут обрабатываться этой ситуацией, когда информация будет

274
00:22:37,713 --> 00:22:40,129
нести информацию обратно к нам.

275
00:22:40,129 --> 00:22:44,551
Таким образом, это не ошибка, но это ситуация, когда

276
00:22:44,551 --> 00:22:49,440
пользователь не является действительным пользователем или пароль пользователя недействителен.

277
00:22:49,440 --> 00:22:54,880
Вот как они будут обрабатывать процесс входа пользователя в систему.

278
00:22:54,880 --> 00:22:59,666
Кроме того, я добавлю еще один метод здесь, называемый

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

280
00:23:08,832 --> 00:23:12,831
Вполне возможно, что, хотя клиент вошел в систему и

281
00:23:12,831 --> 00:23:18,229
получил веб-токен JSON, через некоторое время срок действия веб-токена JSON может истечь.

282
00:23:18,229 --> 00:23:23,776
И поэтому, если пользователь пытается получить доступ с клиентской стороны с истекшим токеном

283
00:23:23,776 --> 00:23:29,159
к серверу, сервер не сможет аутентифицировать пользователя.

284
00:23:29,159 --> 00:23:34,024
Таким образом, с периодическими интервалами мы можем провести перекрестную проверку, чтобы убедиться, что

285
00:23:34,024 --> 00:23:35,733
веб-токен JSON по-прежнему действителен.

286
00:23:35,733 --> 00:23:41,180
Вот почему я включаю другую конечную точку под названием

287
00:23:41,180 --> 00:23:46,131
CheckJwtToken, поэтому, если вы доберетесь до CheckJwtToken.

288
00:23:46,131 --> 00:23:50,927
Включая токен в заголовок авторизации,

289
00:23:50,927 --> 00:23:55,926
этот вызов вернет true или false, чтобы указать вам,

290
00:23:55,926 --> 00:24:00,125
остается ли веб-токен JSON действительным или нет.

291
00:24:00,125 --> 00:24:04,430
Если он недействителен, то клиентская сторона может инициировать другой логин для

292
00:24:04,430 --> 00:24:09,710
пользователя, чтобы получить новый веб-маркер JSON, если это необходимо.

293
00:24:09,710 --> 00:24:15,470
Итак, чтобы сделать это, мы скажем cors, CorsWithOptions и,

294
00:24:19,500 --> 00:24:23,760
req, res, здесь, как и ожидалось.

295
00:24:25,510 --> 00:24:28,029
И здесь мы скажем,

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

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

298
00:24:54,050 --> 00:24:59,322
И это вернет ошибку, пользователя, информацию.

299
00:25:03,010 --> 00:25:07,005
Вспомните, как мы использовали аутентификатор Passport ранее.

300
00:25:07,005 --> 00:25:11,050
Таким образом, сессия JWT падает здесь.

301
00:25:11,050 --> 00:25:14,759
Так что ранее здесь мы говорим, паспорт.аутентифицировать местный.

302
00:25:14,759 --> 00:25:17,039
Таким образом, это для локальной аутентификации.

303
00:25:17,039 --> 00:25:21,038
Таким образом, это для аутентификации веб-токенов JSON.

304
00:25:21,038 --> 00:25:26,303
Поэтому, когда мы называем это, так как это будет проверять веб-токен JSON,

305
00:25:26,303 --> 00:25:33,820
поэтому я скажу, если (err), верните следующий (err).

306
00:25:33,820 --> 00:25:38,540
А затем пусть обработчик ошибок Express позаботится об этой ситуации.

307
00:25:38,540 --> 00:25:42,895
И тогда мы скажем, если (! ),

308
00:25:47,340 --> 00:25:53,395
Если пользователь не существует, то аналогично, иначе.

309
00:25:53,395 --> 00:25:58,850
Таким образом, это означает, что если объект пользователя был найден из веб-маркера JSON, а

310
00:25:58,850 --> 00:26:04,764
затем загружен в req.user, то это означает, что пользователь является действительным пользователем.

311
00:26:04,764 --> 00:26:06,990
И так можно позволить двигаться вперед.

312
00:26:06,990 --> 00:26:13,770
В противном случае, мы собираемся сказать, что пользователь не существует.

313
00:26:13,770 --> 00:26:18,480
Поэтому нам нужно сделать вывод, что веб-токен JSON истек.

314
00:26:18,480 --> 00:26:24,495
Итак, на данный момент мы отправим res с кодом состояния

315
00:26:29,070 --> 00:26:31,580
401, таким образом, несанкционированным.

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
И тогда мы вернем res,

319
00:26:54,894 --> 00:27:00,970
.json, скажем, {status:,

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

321
00:27:07,131 --> 00:27:15,242
И тогда мы вернем флаг под названием success: false.

322
00:27:15,242 --> 00:27:20,624
И затем, Мы вернем информацию, которую мы

323
00:27:20,624 --> 00:27:26,890
получаем, если пользователь не аутентифицирован как ошибка в этот момент.

324
00:27:30,450 --> 00:27:36,219
В противном случае это означает, что мы достигаем этой точки, когда пользователь является действительным пользователем.

325
00:27:36,219 --> 00:27:40,921
Поэтому в этом случае позвольте мне просто скопировать этот код здесь,

326
00:27:40,921 --> 00:27:45,392
мы отправим код состояния 200, а

327
00:27:45,392 --> 00:27:48,727
затем res.json отправит JWT,

328
00:27:51,140 --> 00:27:55,050
действительный! , и успех будет правдой.

329
00:27:56,550 --> 00:28:03,290
И в третьей части мы отправим информацию о пользователе.

330
00:28:03,290 --> 00:28:07,776
Таким образом, когда эта конечная точка вызывается

331
00:28:07,776 --> 00:28:12,710
с помощью метода get, это проверит, является ли токен действительным или нет.

332
00:28:12,710 --> 00:28:15,580
Если токен действителен, то вы получите этот ответ.

333
00:28:15,580 --> 00:28:17,311
И из флага успеха в ответе

334
00:28:17,311 --> 00:28:20,050
вы можете проверить, является ли веб-токен JSON действительным или нет.

335
00:28:20,050 --> 00:28:24,010
И это полезно на стороне клиента.

336
00:28:24,010 --> 00:28:30,012
Теперь этот паспорт здесь, passport.authenticate здесь,

337
00:28:30,012 --> 00:28:37,720
должен быть снабжен req и res в качестве двух параметров здесь.

338
00:28:37,720 --> 00:28:41,320
Так вот как мы называем этот паспорт.authenticate.

339
00:28:41,320 --> 00:28:45,060
Обратите внимание, что всякий раз, когда вы вызываете pasport.authenticate и

340
00:28:45,060 --> 00:28:49,917
ожидаете эту функцию обратного вызова здесь, вам нужно добавить эту точку, req,

341
00:28:49,917 --> 00:28:53,973
.res, к этому паспорту. authenticate, а затем вернуться сюда.

342
00:28:53,973 --> 00:28:57,915
Таким образом, мы обновили все на стороне сервера.

343
00:28:57,915 --> 00:29:01,900
Итак, давайте сохраним все изменения на стороне сервера.

344
00:29:01,900 --> 00:29:05,400
Итак, теперь наш сервер готов

345
00:29:05,400 --> 00:29:10,680
обрабатывать входящие запросы от нашего углового клиента.

346
00:29:10,680 --> 00:29:13,120
С этим мы завершаем это упражнение.

347
00:29:13,120 --> 00:29:18,010
В этом упражнении мы подготовили наш Express сервер для

348
00:29:18,010 --> 00:29:22,930
обработки входящих запросов от нашего углового клиента.

349
00:29:22,930 --> 00:29:26,890
В следующем упражнении мы рассмотрим клиента Angular более подробно, чтобы

350
00:29:26,890 --> 00:29:32,350
понять, как он взаимодействует с этим дополнительным сервером.

351
00:29:32,350 --> 00:29:37,881
Это хорошее время для вас сделать Git фиксацию с сообщением,

352
00:29:37,881 --> 00:29:40,932
интегрируя клиента и сервера.

353
00:29:40,932 --> 00:29:44,825
[ МУЗЫКА]