1
00:00:03,890 --> 00:00:11,670
Теперь, когда мы поняли аутентификацию на основе токенов с использованием JSON Web Tokens,

2
00:00:11,670 --> 00:00:16,035
а также поняли преимущества использования этого подхода.

3
00:00:16,035 --> 00:00:22,185
Тот факт, что мы сейчас создаем сервер на основе Rest API,

4
00:00:22,185 --> 00:00:24,420
в этом курсе означает, что

5
00:00:24,420 --> 00:00:27,585
аутентификация на основе JSON Web Token

6
00:00:27,585 --> 00:00:31,410
наиболее подходит для этого сервера, который мы создаем.

7
00:00:31,410 --> 00:00:40,585
Итак, давайте обновим наш сервер API Rest, чтобы использовать JSON Web Tokens в этом упражнении.

8
00:00:40,585 --> 00:00:45,755
Чтобы начать обновление сервера на вашем терминале,

9
00:00:45,755 --> 00:00:51,935
давайте сначала установим JSON Web Token и модуль паспорта JWT Node.

10
00:00:51,935 --> 00:00:56,445
Итак, в подсказке введите npm, установите,

11
00:00:56,445 --> 00:01:05,640
паспорт JWT JSON Web Token и минус сохранить.

12
00:01:05,640 --> 00:01:15,435
Как вы можете видеть, я использую JSON Web Token 8.3.0 и паспорт JWT 4.0.0 в этом курсе.

13
00:01:15,435 --> 00:01:23,180
Теперь, когда мы завершили установку, давайте перейдем и обновим наш экспресс-сервер.

14
00:01:23,180 --> 00:01:25,700
Перейдя сейчас к нашему коду,

15
00:01:25,700 --> 00:01:30,289
давайте добавим в файл

16
00:01:30,289 --> 00:01:36,335
с именем conflict.js в корневую папку нашего проекта.

17
00:01:36,335 --> 00:01:39,455
Теперь этот файл conflict.js я собираюсь использовать его

18
00:01:39,455 --> 00:01:43,220
для хранения некоторой информации о конфигурации для нашего сервера.

19
00:01:43,220 --> 00:01:49,790
Теперь это способ централизации всей конфигурации для нашего сервера.

20
00:01:49,790 --> 00:01:53,600
В этом файле conflict.js

21
00:01:53,600 --> 00:01:59,825
позвольте мне экспортировать объект JSON здесь.

22
00:01:59,825 --> 00:02:02,490
Итак, мы скажем, SecretKey,

23
00:02:08,510 --> 00:02:11,550
и здесь

24
00:02:19,450 --> 00:02:28,705
я укажу секретный ключ, который я собираюсь использовать для подписания моего JSON Web Token,

25
00:02:28,705 --> 00:02:36,700
а также позвольте мне указать URL-адрес Mongo здесь,

26
00:02:36,700 --> 00:02:41,275
который будет URL-адресом для

27
00:02:41,275 --> 00:02:51,710
моего сервера MongoDB localhost 27017.

28
00:02:52,200 --> 00:02:55,060
После того, как мы завершили это,

29
00:02:55,060 --> 00:02:59,260
мы перейдем к файлу authenticate.js,

30
00:02:59,260 --> 00:03:01,780
а в файле authenticate.js мы

31
00:03:01,780 --> 00:03:10,700
теперь создадим стратегию JWT.

32
00:03:11,250 --> 00:03:16,175
Это стратегия веб-токенов JSON, которая предоставляется

33
00:03:16,175 --> 00:03:25,830
нашим паспортным модулем узла JWT, который мы только что включили, и поэтому мы скажем,

34
00:03:26,300 --> 00:03:32,895
стратегия генеративности паспорта generativity.strategy.

35
00:03:32,895 --> 00:03:35,370
Это предоставит нам

36
00:03:35,370 --> 00:03:40,550
стратегию на основе JSON Web Token для настройки нашего модуля паспорта,

37
00:03:40,550 --> 00:03:46,820
а затем извлеките JWT, который я

38
00:03:46,820 --> 00:03:53,745
также получу из паспорта JWT.

39
00:03:53,745 --> 00:03:55,935
Нам потребуется паспорт JWT,

40
00:03:55,935 --> 00:03:59,565
затем мы скажем «Извлечь JWT».

41
00:03:59,565 --> 00:04:02,655
Затем давайте импортируем

42
00:04:02,655 --> 00:04:10,240
модуль JSON Web Token

43
00:04:10,240 --> 00:04:12,265
, который мы только что установили.

44
00:04:12,265 --> 00:04:15,340
После того, как мы импортировали их,

45
00:04:15,340 --> 00:04:18,370
давайте продолжим и начнем настраивать несколько вещей.

46
00:04:18,370 --> 00:04:26,205
Наряду с этим позвольте мне импортировать конфигурацию, которую я

47
00:04:26,205 --> 00:04:35,840
создал файл config.js, который я только что добавил в свой проект.

48
00:04:35,840 --> 00:04:40,100
Как только я закончу это, позвольте мне пойти вперед и

49
00:04:40,100 --> 00:04:45,650
ввести несколько дополнительных функций, которые я буду экспортировать отсюда.

50
00:04:45,650 --> 00:04:49,200
Скажем, Exports.getToken,

51
00:04:55,160 --> 00:05:02,840
эта функция при поставке с параметром, который я просто вызову пользователя,

52
00:05:02,840 --> 00:05:06,335
который будет объектом JSON,

53
00:05:06,335 --> 00:05:10,145
это создаст токен и даст его нам.

54
00:05:10,145 --> 00:05:16,685
Чтобы создать токен, мы будем использовать модуль jsonwebtoken, который мы только что импортировали.

55
00:05:16,685 --> 00:05:22,140
Итак, здесь мы скажем, что return jwt.sign,

56
00:05:23,750 --> 00:05:31,355
это помогает нам создать JSON Web Token и так внутри, что он

57
00:05:31,355 --> 00:05:34,430
позволит мне поставлять полезную нагрузку, а

58
00:05:34,430 --> 00:05:38,825
полезная нагрузка здесь входит как параметр здесь называется пользователем,

59
00:05:38,825 --> 00:05:42,620
а затем второй параметр - это

60
00:05:42,620 --> 00:05:51,050
секретный или закрытый ключ, который я получаю из конфигурации. секретный ключ,

61
00:05:51,050 --> 00:05:55,260
который я только что настроил немного раньше.

62
00:05:55,630 --> 00:06:02,835
Здесь мы можем предоставить дополнительные варианты.

63
00:06:02,835 --> 00:06:07,055
Один из вариантов, который я поставлю на это...

64
00:06:07,055 --> 00:06:09,410
Хорошо, позвольте мне перейти к следующей строке здесь,

65
00:06:09,410 --> 00:06:14,160
вариант, который я поставлю - ExpiResin.

66
00:06:14,530 --> 00:06:20,945
ExpiResin скажет вам, как долго jsonwebtoken будет

67
00:06:20,945 --> 00:06:27,185
действительным, поэтому в этом случае я говорю 3,600, что означает 3,600 секунд или около часа.

68
00:06:27,185 --> 00:06:32,825
Через час вам придется обновить jsonwebtoken.

69
00:06:32,825 --> 00:06:36,790
Часа достаточно для того, чтобы мы могли протестировать наше приложение.

70
00:06:36,790 --> 00:06:40,370
Вы можете установить это намного дольше, если вы решите.

71
00:06:40,370 --> 00:06:45,110
В реальном приложении вы можете установить это гораздо более длительное значение, возможно,

72
00:06:45,110 --> 00:06:50,075
несколько дней, и ожидать, что пользователь будет повторно аутентифицировать себя каждые несколько дней.

73
00:06:50,075 --> 00:06:52,670
Теперь мы также будем настраивать

74
00:06:52,670 --> 00:06:58,025
стратегию на основе jsonwebtoken для нашего заявления на паспорт.

75
00:06:58,025 --> 00:07:02,900
Итак, позвольте мне объявить переменную, называемую opts, что

76
00:07:02,900 --> 00:07:12,140
является не чем иным, как параметрами, которые я собираюсь указать для моей стратегии на основе JWT.

77
00:07:12,140 --> 00:07:18,905
Таким образом, мы скажем, что выбирает JWTFromRequest.

78
00:07:18,905 --> 00:07:22,925
Теперь эта опция определяет,

79
00:07:22,925 --> 00:07:28,580
как jsonwebtoken должен быть извлечен из входящего сообщения запроса.

80
00:07:28,580 --> 00:07:33,755
Здесь мы будем использовать экстракт JWT.

81
00:07:33,755 --> 00:07:39,290
Этот экстракт JWT поддерживает различные методы

82
00:07:39,290 --> 00:07:44,970
для извлечения информации из заголовка.

83
00:07:44,970 --> 00:07:49,580
Он скажет из AuthHeader из AuthHeader в качестве токена носителя,

84
00:07:49,580 --> 00:07:51,510
из заголовка, какая схема и так далее.

85
00:07:51,510 --> 00:07:54,380
Если вы прочитаете документацию, он расскажет

86
00:07:54,380 --> 00:07:58,040
вам различные способы извлечения jsonwebtoken.

87
00:07:58,040 --> 00:08:00,770
Вы можете передать токен в теле

88
00:08:00,770 --> 00:08:04,970
входящего сообщения запроса, а затем вы можете извлечь его оттуда,

89
00:08:04,970 --> 00:08:08,255
вы также можете использовать пользовательские экстракторы и так далее.

90
00:08:08,255 --> 00:08:14,180
В этом курсе я собираюсь использовать самый простой метод, вызываемый

91
00:08:14,180 --> 00:08:20,745
из заголовка аутентификации в качестве токена носителя.

92
00:08:20,745 --> 00:08:22,220
Мы уже знакомы с

93
00:08:22,220 --> 00:08:25,055
заголовком аутентификации, потому что, как мы использовали это с

94
00:08:25,055 --> 00:08:30,440
обычной аутентификацией и аутентификацией на основе файлов cookie ранее.

95
00:08:30,440 --> 00:08:32,180
Итак, я просто собираюсь использовать

96
00:08:32,180 --> 00:08:38,350
это же поле заголовка в сообщении запроса, чтобы нести jsonwebtoken.

97
00:08:38,350 --> 00:08:45,270
Поэтому я скажу, что выбор в качестве маркера jsonwebtoken носителя.

98
00:08:45,270 --> 00:08:51,160
Следующий, мы скажем opts.SecretorKey,

99
00:08:56,980 --> 00:09:02,795
это второй параметр, который помогает мне

100
00:09:02,795 --> 00:09:11,670
предоставить секретный ключ, который я собираюсь использовать в своей стратегии для входа.

101
00:09:11,670 --> 00:09:15,875
Так что это другой вариант, который я собираюсь указать здесь.

102
00:09:15,875 --> 00:09:18,065
Как только я указываю эти два,

103
00:09:18,065 --> 00:09:26,390
позвольте мне экспортировать стратегию Passport,

104
00:09:26,390 --> 00:09:30,680
которую я собираюсь настроить здесь, поэтому мы скажем ExportJwtPassport,

105
00:09:30,680 --> 00:09:34,355
тогда мы скажем passport.use.

106
00:09:34,355 --> 00:09:37,940
Вспомните, как вы указывали локальную стратегию ранее.

107
00:09:37,940 --> 00:09:42,035
Здесь мы указываем стратегию на основе JWT,

108
00:09:42,035 --> 00:09:47,895
тогда мы создадим новую стратегию JWT,

109
00:09:47,895 --> 00:09:51,320
напомним, что мы только что импортировали стратегию JWT

110
00:09:51,320 --> 00:09:56,615
здесь, что мы будем использовать для создания новой стратегии.

111
00:09:56,615 --> 00:10:01,235
Эта стратегия JWT принимает

112
00:10:01,235 --> 00:10:07,675
объект options, который я только что создал в качестве первого параметра.

113
00:10:07,675 --> 00:10:14,210
Варианты стратегии и второй - это функция проверки, которую мне нужно поставить,

114
00:10:14,210 --> 00:10:18,050
и поэтому функция проверки я собираюсь предоставить ее в следующей строке здесь,

115
00:10:18,050 --> 00:10:28,545
мы скажем functionJWT_Payload.

116
00:10:28,545 --> 00:10:33,900
Сделано. Таким образом, когда эта функция

117
00:10:33,900 --> 00:10:39,270
вызывается, выполняется обратный вызов, который предоставляется паспортом.

118
00:10:39,270 --> 00:10:44,270
Таким образом, всякий раз, когда у вас есть паспорт, который

119
00:10:44,270 --> 00:10:46,750
вы настраиваете с помощью новой стратегии, вам нужно указать второй параметр.

120
00:10:46,750 --> 00:10:48,460
С помощью этого параметра

121
00:10:48,460 --> 00:10:52,235
вы будете передавать обратно информацию в паспорт, который он затем будет

122
00:10:52,235 --> 00:10:57,780
использовать для загрузки вещей в сообщение запроса.

123
00:10:57,780 --> 00:11:00,710
Таким образом, когда паспорт анализирует сообщение запроса,

124
00:11:00,710 --> 00:11:04,110
он будет использовать стратегию, а затем извлекать информацию,

125
00:11:04,110 --> 00:11:09,540
а затем загрузить ее в наше сообщение запроса.

126
00:11:09,540 --> 00:11:13,905
Итак, так как это случается, что это функция,

127
00:11:13,905 --> 00:11:19,795
я просто собираюсь использовать функцию стрелки здесь,

128
00:11:19,795 --> 00:11:22,160
я увлекался функциями стрелок.

129
00:11:22,160 --> 00:11:25,650
Итак, позвольте мне создать это как функцию стрелки здесь,

130
00:11:25,650 --> 00:11:28,345
и внутри этой функции,

131
00:11:28,345 --> 00:11:30,465
мы будем определять функцию.

132
00:11:30,465 --> 00:11:32,970
Итак, что мы делаем внутри функции?

133
00:11:32,970 --> 00:11:37,420
Позвольте мне сделать console.log

134
00:11:38,370 --> 00:11:44,020
полезной нагрузки JWT, а затем

135
00:11:44,660 --> 00:11:49,995
позвольте мне просто выйти из опции, входящей сюда,

136
00:11:49,995 --> 00:11:51,770
опция полезной нагрузки JWT здесь,

137
00:11:51,770 --> 00:11:55,420
чтобы вы могли увидеть, что находится внутри полезной нагрузки JWT.

138
00:11:55,420 --> 00:12:04,250
Затем мы будем искать пользователя, сказав user.findone,

139
00:12:04,250 --> 00:12:14,020
а затем я знаю, что в jwt.payload

140
00:12:14,020 --> 00:12:17,210
есть поле ID, которое входит.

141
00:12:17,210 --> 00:12:21,360
Итак, это то, что я собираюсь назначить в качестве поля ID здесь.

142
00:12:21,360 --> 00:12:26,040
Итак, я скажу, user.findone и второй

143
00:12:26,040 --> 00:12:36,190
- это функция обратного вызова.

144
00:12:36,870 --> 00:12:45,295
Как вы понимаете, этот метод пользователя Mongoose, и вы пытаетесь найти.

145
00:12:45,295 --> 00:12:54,665
Итак, мы скажем, если ошибка, то возвращение сделано.

146
00:12:54,665 --> 00:12:57,945
Что это сделало? Это сделано - обратный вызов, который

147
00:12:57,945 --> 00:13:02,155
паспорт будет передавать в вашу стратегию здесь.

148
00:13:02,155 --> 00:13:04,965
Итак, мы будем вызывать эту выполненную функцию.

149
00:13:04,965 --> 00:13:11,200
Это делается в паспорте, принимает три параметра.

150
00:13:12,890 --> 00:13:20,400
Таким образом, вы можете увидеть три части информации, которую это сделано ожидает, что он говорит, ошибка: любой.

151
00:13:20,400 --> 00:13:24,525
Итак, если у вас есть ошибка, вы передадите ее в качестве первого параметра.

152
00:13:24,525 --> 00:13:26,495
Второй параметр, пользователь? ,

153
00:13:26,495 --> 00:13:28,245
Если пользователь существует,

154
00:13:28,245 --> 00:13:33,770
то значение пользователя будет передано, а затем, если какая-либо информация? :, любой.

155
00:13:33,770 --> 00:13:37,100
Таким образом, эти два являются необязательными параметрами и поэтому,

156
00:13:37,100 --> 00:13:38,690
если вы передаете какую-либо информацию,

157
00:13:38,690 --> 00:13:42,145
то это будет использоваться в приложении.

158
00:13:42,145 --> 00:13:44,650
Если я передаю false в качестве второго параметра,

159
00:13:44,650 --> 00:13:47,515
это означает, что пользователь не существует или что.

160
00:13:47,515 --> 00:13:50,810
Таким образом, он будет интерпретировать, что пользователь не существует.

161
00:13:50,810 --> 00:13:52,335
Итак, я мог бы сказать, err,

162
00:13:52,335 --> 00:13:54,900
false, потому что это ошибка.

163
00:13:54,900 --> 00:13:58,080
Итак, я не собираюсь передавать пользовательское значение там,

164
00:13:58,080 --> 00:14:00,660
я просто собираюсь передать в false.

165
00:14:00,660 --> 00:14:06,040
Там, следующий,

166
00:14:06,040 --> 00:14:11,510
мы можем сказать, иначе if (пользователь).

167
00:14:11,510 --> 00:14:15,860
Итак, если пользователь не равен нулю,

168
00:14:15,860 --> 00:14:18,960
мы скажем, return done (null).

169
00:14:19,230 --> 00:14:22,210
Ошибки нет, поэтому первый параметр будет

170
00:14:22,210 --> 00:14:25,080
нулевым, а второй параметр - это пользователь,

171
00:14:25,080 --> 00:14:29,895
но мы только что получили из MongoDB.

172
00:14:29,895 --> 00:14:35,445
В противном случае мы вернемся

173
00:14:35,445 --> 00:14:41,395
с null, false.

174
00:14:41,395 --> 00:14:43,650
Итак, в последнем случае,

175
00:14:43,650 --> 00:14:45,100
мы не смогли найти пользователя,

176
00:14:45,100 --> 00:14:47,120
поэтому мы будем передавать false.

177
00:14:47,120 --> 00:14:50,200
Итак, мы будем справляться с этим вот так.

178
00:14:50,200 --> 00:14:53,345
Если вы хотите, вы можете создать новую учетную запись пользователя на этом этапе,

179
00:14:53,345 --> 00:14:58,365
но я собираюсь сохранить это просто так, чтобы это было легко для нас понять.

180
00:14:58,365 --> 00:15:00,810
Итак, мы просто скажем, нулевое, ложное. Это шесть.

181
00:15:00,810 --> 00:15:07,475
Итак, это стратегия паспорта JsonWebToken, которую я только что настроил здесь.

182
00:15:07,475 --> 00:15:11,420
Кроме того, позвольте мне экспортировать

183
00:15:11,420 --> 00:15:19,450
еще одну функцию отсюда под названием VerifyUser.

184
00:15:19,450 --> 00:15:21,110
Теперь, эта функция VerifyUser,

185
00:15:21,110 --> 00:15:24,935
я собираюсь использовать ее для проверки входящего пользователя.

186
00:15:24,935 --> 00:15:28,810
Итак, здесь я буду использовать passport.authenticate.

187
00:15:28,890 --> 00:15:36,440
Итак, pasport.authenticate, стратегия - это стратегия jwt, которую я только что настроил,

188
00:15:36,440 --> 00:15:39,490
стратегия JsonWebToken, которую я только что настроил.

189
00:15:39,490 --> 00:15:41,625
Затем вторая часть,

190
00:15:41,625 --> 00:15:46,305
я бы сказал, сессия: ложь.

191
00:15:46,305 --> 00:15:47,740
Таким образом, это означает, что

192
00:15:47,740 --> 00:15:51,305
мы не собираемся создавать сессии в этом случае.

193
00:15:51,305 --> 00:15:58,215
Как вы помните, обратное приложение,

194
00:15:58,215 --> 00:16:00,530
мы используем проверку подлинности на основе токенов.

195
00:16:00,530 --> 00:16:02,435
Так что мы не собираемся создавать сеансы.

196
00:16:02,435 --> 00:16:07,690
Поэтому я установил этот сеанс опций на false здесь,

197
00:16:07,690 --> 00:16:11,795
и, конечно же, первый указал стратегию, которую я собираюсь использовать.

198
00:16:11,795 --> 00:16:14,050
Таким образом, для проверки пользователя

199
00:16:14,050 --> 00:16:15,930
я буду использовать стратегию JWT.

200
00:16:15,930 --> 00:16:18,110
Как работает стратегия JWT?

201
00:16:18,110 --> 00:16:20,540
Во входящем

202
00:16:21,040 --> 00:16:26,845
запросе токен будет включен в заголовок аутентификации, как мы видели здесь.

203
00:16:26,845 --> 00:16:29,950
Мы сказали, что заголовок аутентификации как токен носителя.

204
00:16:29,950 --> 00:16:33,530
Если это включено, то это будет извлечено и будет

205
00:16:33,530 --> 00:16:38,210
использоваться для аутентификации пользователя на основе токена.

206
00:16:38,210 --> 00:16:47,770
Незначительное исправление здесь, это должно быть user.Findone_ID равно jwt_payload. _id,

207
00:16:47,770 --> 00:16:56,475
потому что это значение id, которое находится внутри полезной нагрузки моего JsonWebToken.

208
00:16:56,475 --> 00:17:01,615
Итак, мы ищем пользователя с этим заданным идентификатором.

209
00:17:01,615 --> 00:17:06,170
Итак, как только мы закончили это, то теперь,

210
00:17:06,170 --> 00:17:11,790
вторая часть, которую нам нужно сделать, это то, что нам нужно где-то создать токен.

211
00:17:11,790 --> 00:17:14,005
Теперь, где мы создаем токен?

212
00:17:14,005 --> 00:17:20,290
Таким образом, это то, что мы делаем в файле users.js, очень полезно для нас.

213
00:17:20,290 --> 00:17:22,270
В файле users.js

214
00:17:22,270 --> 00:17:27,180
напомните, что у вас уже есть эта конечная точка под названием login.

215
00:17:27,180 --> 00:17:28,700
В конечной точке входа

216
00:17:28,700 --> 00:17:33,410
вы использовали имя пользователя и пароль для аутентификации пользователя.

217
00:17:33,410 --> 00:17:38,030
Таким образом, даже с JsonWebToken для выпуска JsonWebToken,

218
00:17:38,030 --> 00:17:41,959
вам сначала нужно аутентифицировать пользователя, используя одну из других стратегий,

219
00:17:41,959 --> 00:17:44,630
и если вы собираетесь использовать локальную стратегию сначала,

220
00:17:44,630 --> 00:17:49,715
мы проведем аутентификацию пользователя, используя имя пользователя и пароль.

221
00:17:49,715 --> 00:17:53,415
После того, как пользователь

222
00:17:53,415 --> 00:17:55,885
будет аутентифицирован с именем пользователя и паролем, мы выдадим токен пользователю, говорящему:

223
00:17:55,885 --> 00:17:57,330
«Хорошо, вы действительный пользователь,

224
00:17:57,330 --> 00:17:58,630
я собираюсь дать вам токен».

225
00:17:58,630 --> 00:18:02,390
Все последующие запросы будут просто нести токен

226
00:18:02,390 --> 00:18:06,860
в заголовке входящего сообщения запроса.

227
00:18:06,860 --> 00:18:10,415
Итак, раньше мы создавали сеансы.

228
00:18:10,415 --> 00:18:11,840
Когда пользователь аутентифицирован,

229
00:18:11,840 --> 00:18:13,935
мы больше не будем использовать сеансы.

230
00:18:13,935 --> 00:18:17,640
Вместо этого, когда пользователь аутентифицируется с помощью локальной стратегии,

231
00:18:17,640 --> 00:18:20,110
мы выдадим токен пользователю.

232
00:18:20,110 --> 00:18:25,955
Итак, внутри этого метода router.post, который мы сделали на этой конечной точке /login,

233
00:18:25,955 --> 00:18:31,730
я собираюсь создать токен и передать этот токен обратно пользователю.

234
00:18:31,730 --> 00:18:36,980
Итак, здесь мы скажем router.post.

235
00:18:38,550 --> 00:18:40,785
Позвольте мне создать токен.

236
00:18:40,785 --> 00:18:42,630
Чтобы создать токен,

237
00:18:42,630 --> 00:18:50,150
у нас есть эта функция в модуле аутентификации под названием Authenticate.getToken.

238
00:18:51,250 --> 00:18:54,325
Итак, напомним, что у нас уже есть,

239
00:18:54,325 --> 00:18:57,050
чтобы воспользоваться этим, конечно,

240
00:18:57,050 --> 00:18:59,210
еще до того, как мы начнем там,

241
00:18:59,210 --> 00:19:02,750
мне нужно импортировать аутентификацию.

242
00:19:05,940 --> 00:19:17,720
Модуль здесь. Итак, мы скажем, требуется аутентификация. /аутентифицировать.

243
00:19:18,000 --> 00:19:26,740
Итак, тогда, когда в вашем коде здесь,

244
00:19:26,740 --> 00:19:29,270
мы можем сказать Authenticate.getToken,

245
00:19:31,530 --> 00:19:37,585
и getToken принимает параметр здесь.

246
00:19:37,585 --> 00:19:41,875
Теперь, вспомните, возвращаясь к файлу authenticate.js.

247
00:19:41,875 --> 00:19:46,665
Файл authenticate.js принимает один параметр здесь

248
00:19:46,665 --> 00:19:53,105
, который будет использоваться в качестве полезной нагрузки при создании JsonWebToken.

249
00:19:53,105 --> 00:19:55,785
Итак, в файле users.js

250
00:19:55,785 --> 00:19:59,230
я собираюсь создать токен, предоставив полезную нагрузку,

251
00:19:59,230 --> 00:20:02,890
которая содержит только идентификатор пользователя.

252
00:20:02,890 --> 00:20:06,070
Итак, мы скажем id: req.user. _id.

253
00:20:06,740 --> 00:20:11,940
Этого достаточно для создания JsonWebToken.

254
00:20:11,940 --> 00:20:15,315
Мы не хотим включать какую-либо другую информацию пользователя.

255
00:20:15,315 --> 00:20:18,690
Если вы решите, вы можете включить другие части информации о пользователе,

256
00:20:18,690 --> 00:20:21,715
но я бы предложил сохранить JsonWebToken маленьким.

257
00:20:21,715 --> 00:20:25,700
Идентификатор пользователя достаточно, потому что если вам нужно искать пользователя,

258
00:20:25,700 --> 00:20:32,840
идентификатора пользователя достаточно для поиска в MongoDB для пользователя.

259
00:20:32,840 --> 00:20:39,230
Итак, я просто собираюсь кодировать только идентификатор пользователя здесь.

260
00:20:39,230 --> 00:20:44,930
Теперь вы знаете, что req.user уже будет присутствовать,

261
00:20:44,930 --> 00:20:50,530
потому что, когда pasport.authenticate («локальный») успешно аутентифицирует пользователя,

262
00:20:50,530 --> 00:20:54,650
это загрузит свойство пользователя в сообщение запроса.

263
00:20:54,650 --> 00:20:57,300
Вот почему я могу сделать это здесь.

264
00:20:57,300 --> 00:21:01,830
Итак, это то, что я буду использовать для создания токена.

265
00:21:01,900 --> 00:21:05,120
Теперь, как только токен создан,

266
00:21:05,120 --> 00:21:09,720
я хочу передать этот токен обратно пользователю.

267
00:21:09,720 --> 00:21:15,715
Итак, в объекте rest.json, который я поставляю здесь,

268
00:21:15,715 --> 00:21:21,755
я уже ношу флаг успеха, а также

269
00:21:21,755 --> 00:21:23,855
сообщение о статусе здесь.

270
00:21:23,855 --> 00:21:28,270
Позвольте мне добавить токен в

271
00:21:28,270 --> 00:21:34,880
качестве одного из свойств в ответном сообщении здесь.

272
00:21:36,480 --> 00:21:39,475
Итак, токен, который я только что создал,

273
00:21:39,475 --> 00:21:47,595
я передам это обратно как второе свойство внутри этой строки Json здесь.

274
00:21:47,595 --> 00:21:55,370
Итак, теперь, когда мой клиент получает эту строку Json в теле ответного сообщения,

275
00:21:55,370 --> 00:21:59,870
он может войти и извлечь токен оттуда.

276
00:22:00,140 --> 00:22:05,500
Вот оно. Итак, мы обновили файл users.js,

277
00:22:05,500 --> 00:22:08,630
и теперь вы можете увидеть, как маркер будет

278
00:22:08,630 --> 00:22:12,690
создан и отправлен обратно пользователю, когда пользователь успешно аутентифицирован.

279
00:22:12,690 --> 00:22:16,330
Теперь эта схема также может быть использована

280
00:22:16,330 --> 00:22:21,250
при использовании сторонней аутентификации, как на основе OAuth 2.0,

281
00:22:21,250 --> 00:22:23,525
который мы рассмотрим в следующем модуле.

282
00:22:23,525 --> 00:22:25,695
Теперь процедура будет аналогичной.

283
00:22:25,695 --> 00:22:32,560
Вы будете создавать токен, когда пользователь

284
00:22:32,560 --> 00:22:35,640
будет аутентифицирован сторонним поставщиком аутентификации или OAuth, а затем вы передадите токен обратно пользователю,

285
00:22:35,640 --> 00:22:39,010
в аналогичном подходе, как вы видите здесь.

286
00:22:39,010 --> 00:22:41,285
Теперь, как только мы это сделали,

287
00:22:41,285 --> 00:22:44,255
мы переходим к файлу app.js.

288
00:22:44,255 --> 00:22:53,660
В файле app.js, потому что мы включили конфигурационный файл здесь.

289
00:22:53,660 --> 00:22:59,005
Итак, позвольте мне запросить файл конфигурации здесь,

290
00:22:59,005 --> 00:23:06,465
а затем URL-адрес, который я использую здесь, вместо жесткого кодирования этого URL-адреса,

291
00:23:06,465 --> 00:23:11,345
я скажу config.Mongourl.

292
00:23:11,345 --> 00:23:16,680
Итак, теперь вы видите, как мой файл config.js может быть использован

293
00:23:16,680 --> 00:23:23,520
в качестве централизованного места, где я могу подготовить конфигурацию для моего приложения.

294
00:23:23,520 --> 00:23:29,200
Вот оно. Итак, теперь происходит то, что когда пользователь

295
00:23:29,200 --> 00:23:35,010
аутентифицируется на конечной точке /login и пользователь успешно аутентифицирован,

296
00:23:35,010 --> 00:23:40,840
токен будет создан сервером и отправлен обратно клиенту или пользователю.

297
00:23:40,840 --> 00:23:43,765
Таким образом, клиент будет включать токен в

298
00:23:43,765 --> 00:23:47,765
каждый последующий входящий запрос в заголовок авторизации.

299
00:23:47,765 --> 00:23:50,590
Теперь, как он включает заголовок авторизации?

300
00:23:50,590 --> 00:23:54,220
Давайте вернемся к authentic.js и здесь,

301
00:23:54,220 --> 00:24:01,625
вы видите, что мы сказали ExtractJWT.FromAuthHeaderasBearerToken здесь.

302
00:24:01,625 --> 00:24:06,290
Таким образом, это будет включено в заголовок аутентификации в качестве токена носителя.

303
00:24:06,290 --> 00:24:08,385
Я покажу вам, как это делается,

304
00:24:08,385 --> 00:24:15,535
а затем мы используем почтальона, чтобы включить токен носителя в заголовок аутентификации.

305
00:24:15,535 --> 00:24:17,690
Теперь, когда это приходит,

306
00:24:17,690 --> 00:24:21,060
вы помните, что прямо ниже здесь,

307
00:24:21,060 --> 00:24:25,095
вы настроили этот метод здесь под названием VerifyUser,

308
00:24:25,095 --> 00:24:30,635
который вызывает аутентификацию паспорта с помощью JWT.

309
00:24:30,635 --> 00:24:34,460
Таким образом, этот использует токен, который

310
00:24:34,460 --> 00:24:38,620
входит в заголовок аутентификации, а затем проверяет пользователя.

311
00:24:38,620 --> 00:24:41,980
Таким образом, в любое время, когда я хочу проверить подлинность пользователя,

312
00:24:41,980 --> 00:24:43,855
я могу просто вызвать пользователя verify,

313
00:24:43,855 --> 00:24:49,115
и это инициирует вызов passport.authenticate и проверяет sser.

314
00:24:49,115 --> 00:24:50,315
Если это будет успешным,

315
00:24:50,315 --> 00:24:51,800
это позволит мне продолжить работу.

316
00:24:51,800 --> 00:24:55,620
Эта процедура очень похожа на то, что вы сделали в

317
00:24:55,620 --> 00:25:01,610
файле users.js, где вы вызываете тот же паспорт.authenticate («локальный»).

318
00:25:01,720 --> 00:25:04,320
Итак, если это успешно,

319
00:25:04,320 --> 00:25:05,885
то вы идете вперед.

320
00:25:05,885 --> 00:25:10,930
В случае сбоя функция аутентификации вернет

321
00:25:10,930 --> 00:25:16,050
клиенту сообщение об ошибке, в котором говорится, что пользователь не авторизован.

322
00:25:16,050 --> 00:25:18,345
Итак, об этом уже позаботились.

323
00:25:18,345 --> 00:25:23,020
Итак, теперь, когда мы включили это в мой файл authenticate.js,

324
00:25:23,020 --> 00:25:26,050
любое место, в котором я хочу проверить пользователя,

325
00:25:26,050 --> 00:25:27,480
я могу просто вызвать

326
00:25:27,480 --> 00:25:31,210
эту функцию VerifyUser, которую

327
00:25:31,210 --> 00:25:34,320
я указал здесь, или экспорт, который я указал здесь,

328
00:25:34,320 --> 00:25:37,220
который мы будем вызывать passport.authenticate с помощью

329
00:25:37,220 --> 00:25:40,540
стратегия JWT для аутентификации пользователя.

330
00:25:40,540 --> 00:25:42,440
Итак, как нам это использовать?

331
00:25:42,440 --> 00:25:47,785
Теперь мы собираемся пойти в каждый из наших маршрутизаторов

332
00:25:47,785 --> 00:25:56,945
и контролировать опции на всех маршрутах, которые мы хотим контролировать.

333
00:25:56,945 --> 00:26:00,300
Итак, возвращаясь к файлу app.js, теперь

334
00:26:00,300 --> 00:26:07,925
, когда мы не используем сеансы, я собираюсь удалить этот сеанс отсюда,

335
00:26:07,925 --> 00:26:10,150
потому что мы больше не используем сеансы.

336
00:26:10,150 --> 00:26:14,990
Аналогичным образом, я также собираюсь удалить этот паспорт.session отсюда.

337
00:26:14,990 --> 00:26:17,580
В этом тоже нет необходимости.

338
00:26:17,580 --> 00:26:20,430
Кроме того, эта проверка подлинности, см. ранее,

339
00:26:20,430 --> 00:26:21,940
когда я настраивал эту проверку подлинности,

340
00:26:21,940 --> 00:26:25,490
эта проверка подлинности применялась к каждому входящему запросу.

341
00:26:25,490 --> 00:26:28,705
Теперь я собираюсь изменить свое приложение, в

342
00:26:28,705 --> 00:26:35,055
результате чего я буду требовать аутентификации только на определенных маршрутах, а не на всех маршрутах.

343
00:26:35,055 --> 00:26:39,665
Итак, позвольте мне полностью удалить эту аутентификацию из app.js.

344
00:26:39,665 --> 00:26:41,995
Итак, теперь, когда запрос приходит,

345
00:26:41,995 --> 00:26:45,850
если он включен/конечная точка,

346
00:26:45,850 --> 00:26:47,080
индекс будет обслуживаться.

347
00:26:47,080 --> 00:26:52,040
Если он находится на конечной точке /users, он позволит вам перейти к

348
00:26:52,040 --> 00:26:57,815
различным маршрутам, которые смонтированы на /users в users.js

349
00:26:57,815 --> 00:27:00,900
, а затем к остальным маршрутам.

350
00:27:00,900 --> 00:27:03,420
То, что я собираюсь сделать сейчас, это оставить

351
00:27:03,420 --> 00:27:07,250
общедоступную папку открытой для всех, чтобы получить доступ.

352
00:27:07,250 --> 00:27:09,145
Теперь, во многих приложениях,

353
00:27:09,145 --> 00:27:10,665
это может быть просто отлично.

354
00:27:10,665 --> 00:27:13,045
Так что, я оставлю это открытым.

355
00:27:13,045 --> 00:27:14,825
Теперь, на блюдах

356
00:27:14,825 --> 00:27:17,920
, акциях и конечной точке лидеров,

357
00:27:17,920 --> 00:27:20,875
все запросы получить.

358
00:27:20,875 --> 00:27:28,205
Я позволю ответить на них, не требуя никакой аутентификации.

359
00:27:28,205 --> 00:27:30,200
Зачем мне это делать?

360
00:27:30,200 --> 00:27:33,190
Если пользователь выполняет запрос на получение,

361
00:27:33,190 --> 00:27:35,455
пользователь просто хочет получить информацию.

362
00:27:35,455 --> 00:27:40,490
Итак, например, на стороне клиента, если я реализую веб-приложение с помощью Angular

363
00:27:40,490 --> 00:27:46,290
или клиентское приложение с использованием Ionic или собственного сценария,

364
00:27:46,290 --> 00:27:49,920
тогда, возможно, я хочу реализовать свое приложение

365
00:27:49,920 --> 00:27:54,310
таким образом, чтобы на главной странице уже

366
00:27:54,310 --> 00:27:57,715
отображалась информация, генетическая информация, которую вы хотите сделать доступным для всех, кто

367
00:27:57,715 --> 00:28:01,590
посещает ваш веб-сайт или открывает ваше приложение.

368
00:28:01,590 --> 00:28:04,360
Таким образом, там можно отобразить основную информацию.

369
00:28:04,360 --> 00:28:08,060
Но если вы хотите что-то изменить,

370
00:28:08,060 --> 00:28:12,110
вы ожидаете, что пользователь будет аутентифицирован.

371
00:28:12,110 --> 00:28:16,255
Таким образом, вы разрешаете операции POST,

372
00:28:16,255 --> 00:28:21,110
операции ввода и удаления выполняться только аутентифицированными пользователями.

373
00:28:21,110 --> 00:28:23,605
Аналогично, например, для комментариев

374
00:28:23,605 --> 00:28:30,280
можно сказать, что комментарии могут быть размещены или изменены только аутентифицированными пользователями.

375
00:28:30,280 --> 00:28:34,570
Таким образом, вы можете ограничить только некоторые маршруты для аутентифицированных пользователей,

376
00:28:34,570 --> 00:28:37,940
другой маршрут вы можете оставить их открытыми. Как нам это сделать?

377
00:28:37,940 --> 00:28:41,180
Теперь это то, где пользователю проверить, что мы

378
00:28:41,180 --> 00:28:45,055
экспортировали из файла authenticate.js, пригодится.

379
00:28:45,055 --> 00:28:49,460
Теперь вместо того, чтобы контролировать все конечные точки,

380
00:28:49,460 --> 00:28:53,190
все различные операции по тарелкам, акциям

381
00:28:53,190 --> 00:28:54,740
и лидерам в точках,

382
00:28:54,740 --> 00:28:58,240
мы будем открывать только операции get для кого угодно,

383
00:28:58,240 --> 00:29:00,830
но

384
00:29:00,830 --> 00:29:04,995
операции post, put и delete будут ограничены только аутентифицированными пользователями.

385
00:29:04,995 --> 00:29:10,350
В назначении вы добавите еще в одну категорию пользователей, называемых администраторами.

386
00:29:10,350 --> 00:29:15,320
Теперь вы ограничите определенные операции, которые будут выполняться только администраторами.

387
00:29:15,320 --> 00:29:18,460
Так, например, изменение блюд

388
00:29:18,460 --> 00:29:22,530
или удаление информации о блюдах из базы данных,

389
00:29:22,530 --> 00:29:24,600
будет ограничено только администраторами.

390
00:29:24,600 --> 00:29:30,000
Но основные пользователи могут размещать комментарии,

391
00:29:30,000 --> 00:29:32,470
изменять комментарии, которые они опубликовали,

392
00:29:32,470 --> 00:29:35,450
и, возможно, даже сохранять некоторые любимые блюда.

393
00:29:35,450 --> 00:29:38,520
Мы сделаем эту часть в четвертом модуле.

394
00:29:38,520 --> 00:29:42,735
Итак, как мы контролируем конкретные маршруты?

395
00:29:42,735 --> 00:29:46,210
Таким образом, это место, где мы должны войти в каждый из маршрутизаторов,

396
00:29:46,210 --> 00:29:50,365
а затем импортировать элементы управления на определенных маршрутах.

397
00:29:50,365 --> 00:29:53,945
Итак, давайте начнем с маршрута блюд.

398
00:29:53,945 --> 00:29:55,770
Итак, для маршрута блюд,

399
00:29:55,770 --> 00:29:59,950
вы вспомните, что это контролируется в файле dishRouter.js.

400
00:29:59,950 --> 00:30:02,515
Итак, перейдя к dishRouter.js,

401
00:30:02,515 --> 00:30:07,450
давайте сначала импортируем аутентификацию здесь.

402
00:30:07,450 --> 00:30:13,400
Итак, скажем, const authenticate

403
00:30:17,010 --> 00:30:24,700
требует../authenticate, потому что этот

404
00:30:24,700 --> 00:30:29,110
файл authenticator.js находится в папке более высокого уровня.

405
00:30:29,110 --> 00:30:32,105
Итак, помните../аутентифицируйте здесь.

406
00:30:32,105 --> 00:30:34,505
Итак, как только вы импортируете аутентификацию,

407
00:30:34,505 --> 00:30:37,965
для маршрута маршрутизатора тарелки для этого маршрута

408
00:30:37,965 --> 00:30:42,560
, операция get, я собираюсь разрешить без каких-либо проблем.

409
00:30:42,560 --> 00:30:44,820
Итак, это открыто.

410
00:30:44,820 --> 00:30:47,025
Так что я не собираюсь накладывать никаких ограничений.

411
00:30:47,025 --> 00:30:51,750
Из сообщения, если мы хотим применить несколько промежуточного программного обеспечения,

412
00:30:51,750 --> 00:30:56,035
мы можем просто добавить основной внутри этого позади другого.

413
00:30:56,035 --> 00:30:58,050
Теперь, когда вызывается сообщение,

414
00:30:58,050 --> 00:31:02,295
прямо сейчас вы просто выполняете эту функцию здесь.

415
00:31:02,295 --> 00:31:04,150
Теперь как раз перед этим

416
00:31:04,150 --> 00:31:12,400
я могу войти и сказать, Authenticate.verifyUser, там.

417
00:31:12,400 --> 00:31:13,805
Итак, что это делает?

418
00:31:13,805 --> 00:31:17,210
Это говорит, что если поступит запрос на пост,

419
00:31:17,210 --> 00:31:20,940
я сначала выполню это промежуточное программное обеспечение,

420
00:31:20,940 --> 00:31:24,805
которое я экспортировал из файла authentic.js,

421
00:31:24,805 --> 00:31:26,100
я сначала применяю

422
00:31:26,100 --> 00:31:32,075
это, что эквивалентно тому, что паспорт аутентифицирует JWT, и вы проверяете пользователя.

423
00:31:32,075 --> 00:31:34,655
Тогда, если это

424
00:31:34,655 --> 00:31:38,890
будет успешно, то я перейду, чтобы сделать остальное.

425
00:31:38,890 --> 00:31:42,955
Если проверка подлинности завершается неудачей на данном этапе,

426
00:31:42,955 --> 00:31:46,290
проверка подлинности паспорта будет отвечать

427
00:31:46,290 --> 00:31:49,395
клиенту с соответствующим сообщением об ошибке.

428
00:31:49,395 --> 00:31:51,640
Таким образом, это уже обрабатывается паспортной аутентификацией,

429
00:31:51,640 --> 00:31:54,350
поэтому мне не нужно беспокоиться ничего за пределами этого момента.

430
00:31:54,350 --> 00:31:58,300
Если я пересек это промежуточное программное обеспечение, а затем

431
00:31:58,300 --> 00:32:02,990
выполнил следующую функцию, что означает, что моя аутентификация была успешной,

432
00:32:02,990 --> 00:32:05,560
поэтому я могу продолжить с этого момента.

433
00:32:05,560 --> 00:32:11,760
Таким образом, это действует в качестве барьера для этого метода поста.

434
00:32:11,760 --> 00:32:14,860
Теперь, используя тот же аргумент,

435
00:32:14,860 --> 00:32:21,435
я могу просто применить это конкретное промежуточное программное обеспечение ко всем другим методам.

436
00:32:21,435 --> 00:32:23,845
Я могу это сделать.

437
00:32:23,845 --> 00:32:26,030
Хотя в этом случае,

438
00:32:26,030 --> 00:32:28,640
положить не собирается ничего делать.

439
00:32:28,640 --> 00:32:30,110
Но в любом случае,

440
00:32:30,110 --> 00:32:33,980
я просто просто ради

441
00:32:33,980 --> 00:32:38,490
единообразия, я буду применять пользователя проверки, чтобы также поставить и, конечно же,

442
00:32:38,490 --> 00:32:41,315
для удаления тоже, я собираюсь применить put.

443
00:32:41,315 --> 00:32:44,805
Аналогичным образом, спустившись к /dishid,

444
00:32:44,805 --> 00:32:48,915
я позволю этому работать без каких-либо проблем.

445
00:32:48,915 --> 00:32:52,470
Post, я применим пользователя проверки.

446
00:32:52,470 --> 00:32:59,600
Поместите также я применим пользователя проверки и для удаления также то же самое.

447
00:32:59,600 --> 00:33:09,105
Для /dishid/comments я собираюсь оставить get open,

448
00:33:09,105 --> 00:33:14,030
это нормально для любого, чтобы получить комментарии о конкретном блюде.

449
00:33:14,030 --> 00:33:17,140
Post, я собираюсь закрыть это,

450
00:33:17,140 --> 00:33:21,995
поэтому только проверенные пользователи могут публиковать комментарии.

451
00:33:21,995 --> 00:33:27,710
Поставьте также я закрою это и удалю тоже.

452
00:33:29,280 --> 00:33:33,035
Вам нужно сделать еще один шаг и сказать:

453
00:33:33,035 --> 00:33:38,230
«Только пользователи, которые разместили комментарий, могут удалять свои собственные сообщения».

454
00:33:38,230 --> 00:33:40,310
Но мы сделаем это в следующем модуле.

455
00:33:40,310 --> 00:33:41,840
На данный момент я скажу:

456
00:33:41,840 --> 00:33:44,415
«Хорошо, проверенный пользователь может удалить любой комментарий».

457
00:33:44,415 --> 00:33:46,715
Это, конечно, не так,

458
00:33:46,715 --> 00:33:48,850
мы можем поставить дополнительные проверки,

459
00:33:48,850 --> 00:33:52,145
но мы сделаем это в следующем модуле этого курса.

460
00:33:52,145 --> 00:33:54,405
Итак, для удаления также я применяю то же самое.

461
00:33:54,405 --> 00:33:58,060
Опять же, для комментариев маршрутизатора тарелки/комментариев Id,

462
00:33:58,060 --> 00:34:00,300
я оставлю его открытым.

463
00:34:00,300 --> 00:34:04,485
Пост, я оставлю его закрытым.

464
00:34:04,485 --> 00:34:12,640
Поставьте также закрыть его, а затем для удаления, также я закрою это.

465
00:34:12,640 --> 00:34:14,970
Удалить, конечно, как я сказал,

466
00:34:14,970 --> 00:34:19,180
операция удаления должна быть разрешена только пользователю, который

467
00:34:19,180 --> 00:34:24,150
создал комментарий, следует попросить удалить его,

468
00:34:24,150 --> 00:34:27,960
но вам нужно настроить несколько дополнительных вещей, чтобы это работало правильно,

469
00:34:27,960 --> 00:34:30,825
что мы сделаем в следующем модуле.

470
00:34:30,825 --> 00:34:36,455
На данный момент мы говорим, что проверенный пользователь может удалить конкретный комментарий, вот и все.

471
00:34:36,455 --> 00:34:42,820
Теперь мы применим тот же принцип к промо-роутеру, а также к лидеру роутера.

472
00:34:42,820 --> 00:34:44,950
Итак, зайдя в промо-роутер,

473
00:34:44,950 --> 00:34:53,100
позвольте мне импортировать аутентификацию,

474
00:34:57,320 --> 00:35:00,870
а затем получить открыт,

475
00:35:00,870 --> 00:35:03,540
так что это лидер маршрутизатор.

476
00:35:03,540 --> 00:35:05,380
Так что, добраться открыт.

477
00:35:05,380 --> 00:35:08,365
Сообщение, я собираюсь контролировать, что,

478
00:35:08,365 --> 00:35:12,865
поставить, контролировать, удалить, контролировать,

479
00:35:12,865 --> 00:35:14,790
лидер маршрутизатор, лидер ID,

480
00:35:14,790 --> 00:35:17,255
получить хорошо, пост,

481
00:35:17,255 --> 00:35:22,330
контролируется, поставить контролируется и удалить контролируется.

482
00:35:22,330 --> 00:35:24,795
То же самое с промо-роутером.

483
00:35:24,795 --> 00:35:38,652
Позвольте мне, потребовать аутентификации,

484
00:35:38,652 --> 00:35:43,570
а затем для получения маршрута открыт,

485
00:35:43,570 --> 00:35:47,109
POST контролируется, поставляется контролируется,

486
00:35:47,109 --> 00:35:50,790
удаление контролируется, то же самое для Promorouter/PromoID.

487
00:35:50,790 --> 00:35:54,460
Get открыт, POST контролируется,

488
00:35:54,460 --> 00:35:58,395
put и delete также контролируются, вот и все.

489
00:35:58,395 --> 00:36:00,225
Давайте сохраним все изменения.

490
00:36:00,225 --> 00:36:02,660
Итак, как только мы завершим все изменения,

491
00:36:02,660 --> 00:36:04,185
давайте сохраним изменения.

492
00:36:04,185 --> 00:36:08,270
Теперь наше приложение готово к тестированию.

493
00:36:08,270 --> 00:36:11,485
Итак, давайте перезапустим наш сервер,

494
00:36:11,485 --> 00:36:14,885
или если сервер не работает,

495
00:36:14,885 --> 00:36:16,590
мы просто запустим сервер.

496
00:36:16,590 --> 00:36:18,770
Переходя к терминалу,

497
00:36:18,770 --> 00:36:20,040
мой сервер не работает.

498
00:36:20,040 --> 00:36:23,930
Итак, позвольте мне запустить сервер, набрав npm start.

499
00:36:24,620 --> 00:36:28,935
Интересно, что он просто вызвал ошибку здесь,

500
00:36:28,935 --> 00:36:32,330
я просто хотел проиллюстрировать вам, что даже я могу ошибаться,

501
00:36:32,330 --> 00:36:34,840
поэтому вы увидите, что здесь есть ошибка, которая говорит:

502
00:36:34,840 --> 00:36:40,275
«Не удается найти module.authenticate», а затем, если я просмотрю код,

503
00:36:40,275 --> 00:36:45,255
я обнаружу, что эта проблема возникла в

504
00:36:45,255 --> 00:36:46,850
где это произошло?

505
00:36:46,850 --> 00:36:48,350
Итак, я просто ищу здесь,

506
00:36:48,350 --> 00:36:50,020
а затем где-то здесь,

507
00:36:50,020 --> 00:36:56,130
я заметил, что эта проблема возникла внутри моего файла users.js.

508
00:36:56,130 --> 00:36:57,870
Итак, прямо там, говорится,

509
00:36:57,870 --> 00:37:00,355
это в файле users.js.

510
00:37:00,355 --> 00:37:05,655
Итак, перейдя к файлу users.js, давайте исправим это.

511
00:37:05,655 --> 00:37:09,015
Перейдя к файлу users.js,

512
00:37:09,015 --> 00:37:14,285
прямо в верхней части, когда мне требуется аутентификация, я сказал:

513
00:37:14,285 --> 00:37:17,555
«.authenticate», и, как я говорил вам, это

514
00:37:17,555 --> 00:37:21,200
должна быть точка, потому что она находится в верхней папке.

515
00:37:21,200 --> 00:37:25,905
Этот файл users.js в папке Routes

516
00:37:25,905 --> 00:37:31,985
и аутентифицировать находится в папке Projects Route, поэтому это должно быть точкой аутентификации.

517
00:37:31,985 --> 00:37:34,660
Итак, если вы совершаете ошибки, вы идете туда,

518
00:37:34,660 --> 00:37:40,450
вот как вам напомнят об ошибке, которую вы ввели.

519
00:37:40,450 --> 00:37:44,540
Итак, давайте сохраним изменения, а затем перезапустите наш сервер.

520
00:37:44,540 --> 00:37:47,795
Опять же, возвращаясь к этому терминалу,

521
00:37:47,795 --> 00:37:54,735
позвольте мне запустить мой сервер, и мой сервер теперь работает,

522
00:37:54,735 --> 00:38:00,235
давайте перейдем к Почтальону, а затем протестируем наше приложение.

523
00:38:00,235 --> 00:38:04,695
Теперь, в Postman, позвольте мне сначала попробовать сделать

524
00:38:04,695 --> 00:38:11,170
GET на локальном хосте: 3000/блюда, а затем, когда я делаю GET,

525
00:38:11,170 --> 00:38:15,620
это успешно, потому что конечная точка GET не контролируется.

526
00:38:15,620 --> 00:38:18,595
Таким образом, я могу сделать GET на блюдах,

527
00:38:18,595 --> 00:38:23,545
я могу сделать GET на акциях,

528
00:38:23,545 --> 00:38:25,420
и все это работает отлично.

529
00:38:25,420 --> 00:38:28,300
Но если я попытаюсь сделать POST на блюдах,

530
00:38:28,300 --> 00:38:32,435
так что позвольте мне найти, где я сделал POST на блюдах.

531
00:38:32,435 --> 00:38:35,245
Здесь я сделал POST на блюда.

532
00:38:35,245 --> 00:38:38,030
Поэтому, когда я попытался сделать POST на посуду,

533
00:38:38,030 --> 00:38:40,540
он сразу говорит несанкционированный.

534
00:38:40,540 --> 00:38:47,410
Таким образом, мой модуль Passport понял, что я не уполномочен, поэтому мне не разрешено это делать,

535
00:38:47,410 --> 00:38:49,825
так что это то, о чем он напоминает мне.

536
00:38:49,825 --> 00:38:52,750
Позвольте мне очистить файлы cookie,

537
00:38:52,750 --> 00:38:57,980
в случае, если вы найдете файл cookie в своем Почтальоне, просто удалите файл cookie,

538
00:38:57,980 --> 00:39:00,410
соответствующий localhost

539
00:39:00,410 --> 00:39:03,815
, потому что этот файл больше не нужен и не потребуется.

540
00:39:03,815 --> 00:39:06,100
Таким образом, даже если я удалю файл cookie, а затем POST,

541
00:39:06,100 --> 00:39:07,990
он все равно скажет несанкционированный.

542
00:39:07,990 --> 00:39:11,715
Итак, я не уполномочен делать эти операции.

543
00:39:11,715 --> 00:39:13,305
Итак, я должен войти в систему.

544
00:39:13,305 --> 00:39:15,430
Теперь, если вы выполнили предыдущее упражнение,

545
00:39:15,430 --> 00:39:19,390
вы бы оставили пользователя, зарегистрированного ранее.

546
00:39:19,390 --> 00:39:25,865
Итак, например, вы бы зарегистрировали этого конкретного пользователя в предыдущем упражнении,

547
00:39:25,865 --> 00:39:29,530
позвольте мне попытаться снова зарегистрировать одного и того же пользователя, и

548
00:39:29,530 --> 00:39:36,090
мой сервер должен жаловаться на то, что userExistSerror, так что это означает, что пользователь существует,

549
00:39:36,090 --> 00:39:38,455
поэтому мне не нужно снова регистрироваться.

550
00:39:38,455 --> 00:39:42,290
Если вы удалили пользователя из вашего MongoDB,

551
00:39:42,290 --> 00:39:47,275
просто зарегистрируйте этого пользователя еще раз, а затем давайте войти в систему.

552
00:39:47,275 --> 00:39:55,830
Таким образом, мы отправим запрос на вход в эту конечную точку.

553
00:39:55,830 --> 00:40:00,640
Итак, когда я отправляю запрос на вход, выполняя POST конечному пользователю,

554
00:40:00,640 --> 00:40:03,365
обратите внимание, что возвращается моим сервером.

555
00:40:03,365 --> 00:40:06,965
Вы сразу же заметите, что в

556
00:40:06,965 --> 00:40:10,830
ответном сообщении вместе с флагом успеха и сообщением о состоянии

557
00:40:10,830 --> 00:40:13,740
вы также получите маркер здесь.

558
00:40:13,740 --> 00:40:16,365
Теперь, этот конкретный токен,

559
00:40:16,365 --> 00:40:17,960
мне нужно скопировать этот токен,

560
00:40:17,960 --> 00:40:21,045
потому что в моих последующих запросах

561
00:40:21,045 --> 00:40:23,535
мне нужно будет включить этот токен.

562
00:40:23,535 --> 00:40:31,610
Итак, позвольте мне перейти к сырой версии этого и что я собираюсь скопировать этот токен.

563
00:40:31,610 --> 00:40:33,875
Этот токен - не что иное, как длинная строка,

564
00:40:33,875 --> 00:40:36,260
поэтому позвольте мне скопировать этот токен.

565
00:40:36,260 --> 00:40:41,765
Тогда теперь, если вам интересно, что содержится в этом токене,

566
00:40:41,765 --> 00:40:44,800
JSON Web Token можно изучить.

567
00:40:44,800 --> 00:40:48,140
Существует конкретный сайт, где вы можете войти и ввести

568
00:40:48,140 --> 00:40:52,235
свой веб-токен JSON, а затем фактически проверить, что находится внутри веб-токена JSON.

569
00:40:52,235 --> 00:40:54,980
Давайте сделаем это в качестве следующего шага.

570
00:40:54,980 --> 00:40:56,685
В окне браузера

571
00:40:56,685 --> 00:41:05,565
просто введите jwt.io, и это приведет вас на этот сайт под названием JSON Web Token jwt.io.

572
00:41:05,565 --> 00:41:07,590
Если вы помните, в лекции

573
00:41:07,590 --> 00:41:10,685
я показал вам структуру JSON Web Token

574
00:41:10,685 --> 00:41:14,290
и показал вам, что JSON Web Token содержит три части: заголовок

575
00:41:14,290 --> 00:41:18,040
, полезную нагрузку и информацию там.

576
00:41:18,040 --> 00:41:19,730
Теперь, в этом случае,

577
00:41:19,730 --> 00:41:25,880
информация здесь, поэтому я собираюсь

578
00:41:25,880 --> 00:41:33,285
вставить свой JSON Web Token в эту левую сторону,

579
00:41:33,285 --> 00:41:37,270
поэтому позвольте мне выбрать это, а затем вставить мой JSON Web Token в

580
00:41:37,270 --> 00:41:41,920
левую сторону в закодированной части, а затем на правой стороне,

581
00:41:41,920 --> 00:41:46,030
он показывает вам, что именно внутри веб-токена JSON, который я только что создал.

582
00:41:46,030 --> 00:41:49,580
Итак, он говорит, что заголовок содержит эти две части информации.

583
00:41:49,580 --> 00:41:54,090
Полезная нагрузка замечает, что она содержит идентификатор

584
00:41:54,090 --> 00:41:59,245
пользователя, а затем подпись внизу здесь.

585
00:41:59,245 --> 00:42:03,995
Итак, это то, что содержится в моем JSON Web Token.

586
00:42:03,995 --> 00:42:07,005
Возвращаясь к

587
00:42:07,005 --> 00:42:12,110
почтальону, позволь мне попробовать взять блюда.

588
00:42:12,110 --> 00:42:15,940
Итак, когда я говорю GET localhost: 3000/diss,

589
00:42:15,940 --> 00:42:18,650
он все равно вернет пустую строку,

590
00:42:18,650 --> 00:42:23,385
пустой массив здесь, потому что моя база данных не содержит ее.

591
00:42:23,385 --> 00:42:29,635
Итак, позвольте мне POST блюдо в мою базу данных.

592
00:42:29,635 --> 00:42:33,290
Итак, я собираюсь выбрать операцию POST и в теле,

593
00:42:33,290 --> 00:42:36,095
вы видите, что мое блюдо здесь.

594
00:42:36,095 --> 00:42:41,215
В заголовке я собираюсь добавить новый заголовок под названием

595
00:42:41,215 --> 00:42:47,240
авторизация, и вы помните, что ранее для базовой авторизации

596
00:42:47,240 --> 00:42:53,425
вы сказали basic, а затем у вас была закодированная строка Base 64 там.

597
00:42:53,425 --> 00:42:58,970
Если вы хотите включить свой JSON Web Token в заголовок авторизации,

598
00:42:58,970 --> 00:43:01,150
потому что в нашем коде

599
00:43:01,150 --> 00:43:04,550
мы сказали авторизацию как токен на предъявителя.

600
00:43:04,550 --> 00:43:08,040
Итак, если вы хотите включить токен в заголовок авторизации,

601
00:43:08,040 --> 00:43:13,275
в авторизации мы скажем носитель, а затем мы вставим ту

602
00:43:13,275 --> 00:43:19,080
строку токена, которую мы только что скопировали из нашего входящего запроса.

603
00:43:19,080 --> 00:43:21,935
Итак, мы вставим строку токена туда.

604
00:43:21,935 --> 00:43:24,360
Итак, это то, что будет содержаться в

605
00:43:24,360 --> 00:43:29,795
заголовке авторизации моего исходящего запроса здесь,

606
00:43:29,795 --> 00:43:33,845
исходящий запрос POST здесь.

607
00:43:33,845 --> 00:43:39,970
Итак, обратите внимание, что левая сторона говорит, что носитель, а правая сторона - это строка,

608
00:43:39,970 --> 00:43:43,230
токен, который я только что скопировал с

609
00:43:43,230 --> 00:43:48,460
точки, где я вошел в систему, а затем позвольте мне отправить сообщение POST

610
00:43:48,460 --> 00:43:57,590
сейчас, и мой POST теперь успешно, и это опубликовано в моей базе данных.

611
00:43:57,590 --> 00:44:01,115
Теперь, если вы хотите быть уверены, что он был опубликован,

612
00:44:01,115 --> 00:44:04,555
давайте сделаем GET, и когда вы делаете GET,

613
00:44:04,555 --> 00:44:12,935
вы можете увидеть, что действительно это блюдо было вставлено в мою базу данных, как показано здесь.

614
00:44:12,935 --> 00:44:19,260
Итак, вот как вы будете использовать JSON Web Tokens в вашем приложении.

615
00:44:19,260 --> 00:44:22,230
Таким образом, всякий раз, когда вам нужно выполнить

616
00:44:22,230 --> 00:44:25,505
операцию POST, PUT или DELETE на любой из конечных точек,

617
00:44:25,505 --> 00:44:27,010
вы будете заключены.

618
00:44:27,010 --> 00:44:33,895
Итак, позвольте мне вернуться к этому запросу POST здесь.

619
00:44:33,895 --> 00:44:35,890
В заголовке вы поместите

620
00:44:35,890 --> 00:44:41,540
это поле авторизации, а затем это будет включено в авторизацию,

621
00:44:41,540 --> 00:44:47,540
вы начнете его с носителя, а затем строку маркера,

622
00:44:47,540 --> 00:44:50,200
после этого пространства носителя,

623
00:44:50,200 --> 00:44:54,215
одно единственное пространство, а затем строка маркера, следующая за этим.

624
00:44:54,215 --> 00:44:58,310
Таким образом, ваши сообщения запроса будут

625
00:44:58,310 --> 00:45:03,140
нести JSON Web Token в заголовке исходящего сообщения запроса.

626
00:45:03,140 --> 00:45:08,220
Вы также можете включить токен в тело исходящего сообщения запроса.

627
00:45:08,220 --> 00:45:10,310
Теперь для этого вам придется настроить

628
00:45:10,310 --> 00:45:18,210
свой экспресс-сервер, особенно дополнительный JWT в

629
00:45:18,210 --> 00:45:21,120
файле authenticate.js, чтобы принять его из

630
00:45:21,120 --> 00:45:24,455
тела, чтобы вы помните, что там мы видели, что

631
00:45:24,455 --> 00:45:28,890
дополнительный JWT поддерживает множество различных способов извлечения

632
00:45:28,890 --> 00:45:33,695
JSON Web Token из входящего запрос.

633
00:45:33,695 --> 00:45:35,090
Итак, там нужно указать,

634
00:45:35,090 --> 00:45:36,670
если вы собираетесь включить его в тело,

635
00:45:36,670 --> 00:45:39,115
вам нужно указать эту информацию там.

636
00:45:39,115 --> 00:45:42,395
Теперь подробно о том, как это сделать, вы можете проконсультироваться с

637
00:45:42,395 --> 00:45:49,885
документацией модуля Passport JWT, чтобы понять, как это делается.

638
00:45:49,885 --> 00:45:54,610
В этом курсе я просто использую это в заголовке авторизации,

639
00:45:54,610 --> 00:45:59,835
как я показал здесь, и это отлично работает в большинстве случаев.

640
00:45:59,835 --> 00:46:02,620
Теперь, если вы разрабатываете веб-приложение,

641
00:46:02,620 --> 00:46:06,635
угловое приложение или приложение Ionic или NativeScript,

642
00:46:06,635 --> 00:46:09,800
вам нужно иметь возможность настроить

643
00:46:09,800 --> 00:46:16,615
это приложение, в котором JSON Web Token будет включен в заголовок авторизации.

644
00:46:16,615 --> 00:46:22,215
В последнем уроке этого курса

645
00:46:22,215 --> 00:46:26,255
я покажу вам, как интегрировать клиента и сервера,

646
00:46:26,255 --> 00:46:29,310
клиента, который вы разработали в предыдущих курсах, с

647
00:46:29,310 --> 00:46:32,495
сервером, который мы разработали в этом курсе.

648
00:46:32,495 --> 00:46:35,120
С этим мы завершаем это упражнение.

649
00:46:35,120 --> 00:46:37,940
В этом упражнении мы видели, как мы

650
00:46:37,940 --> 00:46:42,200
можем настроить наше приложение для использования JSON Web Token,

651
00:46:42,200 --> 00:46:50,555
и мы видели, как мы обрабатываем аутентификацию пользователя с помощью JSON Web Token,

652
00:46:50,555 --> 00:46:55,555
используя поддержку из модуля Passport и модуля Passport JWT,

653
00:46:55,555 --> 00:46:58,605
а также модули JSON Web Token Node.

654
00:46:58,605 --> 00:47:01,090
С этим мы завершаем это упражнение.

655
00:47:01,090 --> 00:47:09,110
Это хорошее время для вас сделать Git Commit с сообщением Passport JWT.