1
00:00:03,950 --> 00:00:09,180
Теперь, когда мы поняли паспорт и как паспорт добавляет

2
00:00:09,180 --> 00:00:14,294
в простое промежуточное программное обеспечение аутентификации для нашего приложения NodeJS,

3
00:00:14,294 --> 00:00:18,435
и обеспечивает гибкий простой в настройке

4
00:00:18,435 --> 00:00:22,935
способ и предоставляет различные стратегии для аутентификации пользователей,

5
00:00:22,935 --> 00:00:27,850
давайте отправимся в путешествие с нашим паспортом.

6
00:00:27,890 --> 00:00:31,020
Для начала этого упражнения,

7
00:00:31,020 --> 00:00:33,945
в качестве первого шага, давайте установим

8
00:00:33,945 --> 00:00:40,135
модули паспорта, локального паспорта и паспорта-локального монгуста в наш сервер путаницы.

9
00:00:40,135 --> 00:00:49,820
Таким образом, в командной строке введите npm instal_passport,

10
00:00:49,820 --> 00:00:59,430
passport-local, паспорт local-mnoose mnus минус сохранить и установить эти три модуля.

11
00:00:59,430 --> 00:01:05,980
Как вы можете видеть на данный момент мы начинаем с

12
00:01:05,980 --> 00:01:15,004
версии паспорта 0.4.0, паспорта-локального 1.0.0 и паспорта-локально-мангуста 5.0.1 в этом курсе.

13
00:01:15,004 --> 00:01:20,110
Теперь, когда мы установили паспорт, паспорт-локальный и паспорт-локаль-мангуст,

14
00:01:20,110 --> 00:01:25,640
давайте перейдем к серверу путаницы и перейдем к файлу user.js.

15
00:01:25,640 --> 00:01:31,325
Мы обновим пользовательскую схему и модель, чтобы использовать паспорт-локаль-мангуст.

16
00:01:31,325 --> 00:01:33,735
Для этого здесь мы скажем, что

17
00:01:33,735 --> 00:01:41,060
var passportLocalMongoose

18
00:01:41,060 --> 00:01:45,390
требует паспорта-локального мангуста.

19
00:01:46,190 --> 00:01:50,330
Таким образом, это мы установим как

20
00:01:50,330 --> 00:01:56,780
плагин mongoose в нашем приложении, и мы можем удалить имя пользователя и

21
00:01:56,780 --> 00:02:00,440
пароль, потому что они будут автоматически добавлены в

22
00:02:00,440 --> 00:02:04,535
passport-local-mongoose плагин здесь и

23
00:02:04,535 --> 00:02:12,980
использовать это как плагин в нашей схеме и модели мангуста.

24
00:02:12,980 --> 00:02:20,160
Мы скажем, пользователь подключите и паспорт-локальный мангуст.

25
00:02:20,160 --> 00:02:23,360
Таким образом, это будет автоматически, как я сказал, добавляя поддержку

26
00:02:23,360 --> 00:02:28,040
имени пользователя и хэшированного хранения пароля с использованием

27
00:02:28,040 --> 00:02:33,305
хэша и соли и добавляя

28
00:02:33,305 --> 00:02:37,235
дополнительные методы в пользовательскую схему

29
00:02:37,235 --> 00:02:40,880
и модель, которые полезны для аутентификации паспорта.

30
00:02:40,880 --> 00:02:48,390
Поэтому, как только мы завершим обновление файла user.js, а затем в нашей папке проекта,

31
00:02:48,390 --> 00:02:55,160
мы создадим новый файл и назовем его как authenticate.js.

32
00:02:55,160 --> 00:02:57,800
В файле authentic.js

33
00:02:57,800 --> 00:03:03,420
позвольте мне импортировать паспорт.

34
00:03:03,940 --> 00:03:10,700
Таким образом, мы скажем, требуется паспорт, и мы собираемся

35
00:03:10,700 --> 00:03:16,700
использовать этот файл для хранения стратегий аутентификации, которые мы будем настраивать.

36
00:03:16,700 --> 00:03:26,195
Так что мы скажем Вар. LocalStrategy требует

37
00:03:26,195 --> 00:03:36,140
паспорт-локальный, поэтому локальный модуль паспорта экспортирует стратегию, которую мы можем использовать для нашего приложения.

38
00:03:36,140 --> 00:03:39,800
Таким образом, мы скажем Passport-Local.strategy,

39
00:03:39,800 --> 00:03:56,700
а затем мы импортируем пользователя из модели пользователя.

40
00:03:58,550 --> 00:04:06,270
Давайте теперь настроим паспорт с новой локальной стратегией,

41
00:04:06,270 --> 00:04:13,970
а затем мы будем экспортировать это из этого файла, потому что это будет модуль узла.

42
00:04:13,970 --> 00:04:23,940
Итак, мы скажем exports.local и мы скажем паспорт, и вы

43
00:04:23,940 --> 00:04:28,580
можете видеть, что паспорт поддерживает различные методы

44
00:04:28,580 --> 00:04:33,710
здесь, поэтому мы скажем использование паспорта и скажем

45
00:04:33,710 --> 00:04:39,125
новую LocalStrategy, а затем это то, где

46
00:04:39,125 --> 00:04:47,715
функции, которые поддерживаются паспорт-локаль-мангуст приходит к нам на помощь.

47
00:04:47,715 --> 00:04:52,225
Таким образом, локальная стратегия должна быть снабжена функцией проверки.

48
00:04:52,225 --> 00:04:55,210
Внутри этой функции мы проверим пользователя.

49
00:04:55,210 --> 00:04:59,090
Эта функция проверки будет вызвана с именем пользователя и паролем, которые

50
00:04:59,090 --> 00:05:03,380
паспорт извлечет из нашего входящего запроса.

51
00:05:03,380 --> 00:05:09,620
Теперь во входящем запросе для LocalStrategy имя пользователя и пароль

52
00:05:09,620 --> 00:05:16,800
должны быть указаны в теле сообщения в виде строки Json.

53
00:05:17,680 --> 00:05:21,560
Опять же, потому что мы делаем body-парсер, так что будет

54
00:05:21,560 --> 00:05:24,500
добавлен в тело сообщения, а затем оттуда паспорт

55
00:05:24,500 --> 00:05:29,000
мы получим это, а затем используем его и поставим имя пользователя и пароль в

56
00:05:29,000 --> 00:05:34,775
качестве параметров для функции проверки, которую мы поставим в LocalStrategy.

57
00:05:34,775 --> 00:05:37,565
Поскольку мы используем плагин passport mongoose,

58
00:05:37,565 --> 00:05:44,915
сам плагин mongoose добавляет эту функцию под названием user.authenticate.

59
00:05:44,915 --> 00:05:51,495
Таким образом, он добавляет этот метод в пользовательскую схему и модель.

60
00:05:51,495 --> 00:05:55,775
Мы собираемся предоставить это как функцию,

61
00:05:55,775 --> 00:06:00,350
которая будет обеспечивать аутентификацию для LocalStrategy.

62
00:06:00,350 --> 00:06:02,540
Теперь, если вы не используете

63
00:06:02,540 --> 00:06:06,875
pasport-local-mongoose, когда вы настраиваете плагин mongoose,

64
00:06:06,875 --> 00:06:08,060
который мы сделали, если

65
00:06:08,060 --> 00:06:12,540
вы не используете его, вам нужно написать свою собственную функцию аутентификации пользователя здесь.

66
00:06:12,540 --> 00:06:15,720
В лекции ранее

67
00:06:15,720 --> 00:06:18,860
я показал вам простую функцию аутентификации пользователя,

68
00:06:18,860 --> 00:06:22,580
которая может быть использована здесь, но тот, который

69
00:06:22,580 --> 00:06:25,610
поставляется модулем pasport-local-mongoose является более

70
00:06:25,610 --> 00:06:30,200
всеобъемлющим, и это то, что мы будем использовать в нашем приложении.

71
00:06:30,200 --> 00:06:36,365
Кроме того, поскольку мы по-прежнему используем сеансы для отслеживания пользователей в нашем приложении,

72
00:06:36,365 --> 00:06:43,775
нам нужно сериализовать и десериализовать пользователя.

73
00:06:43,775 --> 00:06:47,345
Таким образом, это в основном принимает информацию о пользователе.

74
00:06:47,345 --> 00:06:54,815
Теперь напомним, что аутентификация паспорта будет монтировать req.user или свойство пользователя к

75
00:06:54,815 --> 00:06:58,715
сообщению запроса и таким образом,

76
00:06:58,715 --> 00:07:04,610
чтобы информация о пользователе была сериализована и десериализована с помощью

77
00:07:04,610 --> 00:07:17,295
этого слова сериализовать пользователя и паспорт десериализовать пользователя.

78
00:07:17,295 --> 00:07:22,235
Также мы скажем, что пользователь десериализует пользователя.

79
00:07:22,235 --> 00:07:27,920
Эти две функции они сериализуют пользователя и десериализуют пользователя предоставляются

80
00:07:27,920 --> 00:07:35,030
в пользовательской схеме и модели с помощью плагина passport-local-mongoose здесь.

81
00:07:35,030 --> 00:07:38,240
Таким образом, это позаботится о том, что необходимо для

82
00:07:38,240 --> 00:07:42,860
нашей поддержки сеансов в паспорте.

83
00:07:42,860 --> 00:07:48,375
Таким образом, как только мы завершим это обновление файла authenticate.js,

84
00:07:48,375 --> 00:07:54,200
этот файл потребуется везде, где он необходим для нас, чтобы использовать в нашей аутентификации.

85
00:07:54,200 --> 00:07:57,695
Далее, перейдя к файлу users.js,

86
00:07:57,695 --> 00:07:59,795
в файле users.js,

87
00:07:59,795 --> 00:08:04,170
мы сначала импортируем паспорт.

88
00:08:04,170 --> 00:08:09,525
Так что скажем, вар паспорт требует паспорта.

89
00:08:09,525 --> 00:08:16,100
Затем, поскольку мы используем локальный плагин mongoose,

90
00:08:16,100 --> 00:08:20,525
плагин mongoose сам поставляет некоторые метрики, которые

91
00:08:20,525 --> 00:08:25,380
полезны для нас для использования в процессе регистрации и в процессе входа.

92
00:08:25,380 --> 00:08:29,030
Таким образом, спускаясь к сообщению маршрутизатора здесь,

93
00:08:29,030 --> 00:08:34,120
плагин mongoose предоставляет нам метод, называемый регистр,

94
00:08:34,120 --> 00:08:37,275
в пользовательской схеме и модели.

95
00:08:37,275 --> 00:08:44,460
Таким образом, мы скажем, регистрация пользователя, и это будет превращено в говорящего нового пользователя.

96
00:08:44,460 --> 00:08:51,035
Этот новый пользователь является первым параметром, который принимает регистр,

97
00:08:51,035 --> 00:08:58,245
а вторым параметром является пароль req body.

98
00:08:58,245 --> 00:09:05,440
Таким образом, пароль, который входит в качестве второго параметра в теле сообщения.

99
00:09:05,440 --> 00:09:08,460
Поэтому помните, что имя пользователя и пароль передаются,

100
00:09:08,460 --> 00:09:12,020
когда вы регистрируетесь в теле сообщения.

101
00:09:12,020 --> 00:09:14,255
Теперь, в этом случае,

102
00:09:14,255 --> 00:09:19,855
это приведет к функции обратного вызова, предоставляющей ошибку,

103
00:09:19,855 --> 00:09:25,825
и пользователь в качестве двух значений обратного вызова здесь, и, к сожалению,

104
00:09:25,825 --> 00:09:28,790
это тогда не работает в этом случае.

105
00:09:28,790 --> 00:09:33,045
Поэтому мне придется вырезать это отсюда, а затем

106
00:09:33,045 --> 00:09:39,415
вместо этого обрабатывать это внутри этого метода обратного вызова здесь.

107
00:09:39,415 --> 00:09:43,820
Итак, позвольте мне просто отбросить

108
00:09:43,820 --> 00:09:48,060
это, чтобы было легче увидеть код здесь.

109
00:09:48,060 --> 00:09:51,830
Поэтому я скажу, что регистрация пользователя и первый параметр - это

110
00:09:51,830 --> 00:09:53,630
новый пользователь, созданный с

111
00:09:53,630 --> 00:09:57,590
именем пользователя здесь, а второй параметр - это пароль,

112
00:09:57,590 --> 00:10:02,550
а затем результат - это функция обратного вызова, которая вызовет,

113
00:10:02,550 --> 00:10:06,100
мы скажем, ошибка пользователя здесь.

114
00:10:06,100 --> 00:10:11,260
В этом случае мы должны немного отредактировать код здесь.

115
00:10:11,260 --> 00:10:14,620
Итак, в первой части

116
00:10:14,620 --> 00:10:21,850
мы скажем, если ошибка,

117
00:10:21,850 --> 00:10:28,150
то им придется явно отправить ответ.

118
00:10:28,150 --> 00:10:34,945
Итак, я просто скопирую эти два здесь.

119
00:10:34,945 --> 00:10:37,670
Таким образом, мы скажем, если ошибка,

120
00:10:37,740 --> 00:10:40,860
то код статуса res,

121
00:10:40,860 --> 00:10:46,970
мы установим это на 500 и установим тип содержимого заголовка, а затем,

122
00:10:46,970 --> 00:10:52,520
мы установим res json, а затем ошибку, ошибку.

123
00:10:52,520 --> 00:10:56,790
Таким образом, мы построим объект json с ошибкой

124
00:10:56,790 --> 00:11:01,590
в качестве значения свойства error там, а затем отправим это обратно.

125
00:11:01,590 --> 00:11:06,145
Так вот, как вы будете обрабатывать ошибку в этом случае.

126
00:11:06,145 --> 00:11:11,110
В противном случае, то, что мы делаем здесь, это то, что мы

127
00:11:11,110 --> 00:11:18,970
скажем, паспорт аутентифицировать местный.

128
00:11:18,970 --> 00:11:23,810
Поэтому, если мы собираемся использовать паспорт для проверки подлинности пользователя снова.

129
00:11:23,810 --> 00:11:25,930
Так что скажем, паспорт аутентифицирует местный.

130
00:11:25,930 --> 00:11:28,820
Чтобы убедиться, что регистрация пользователя прошла успешно.

131
00:11:28,820 --> 00:11:33,145
мы попытаемся аутентифицировать того же пользователя, что мы только что зарегистрировали, и

132
00:11:33,145 --> 00:11:38,335
здесь мы скажем req res, и это

133
00:11:38,335 --> 00:11:48,355
вернет в качестве третьего значения, что функция внутри которой,

134
00:11:48,355 --> 00:11:52,300
мы собираемся отправить ответ нашему клиенту.

135
00:11:52,300 --> 00:12:01,140
Так что скажем. Позвольте мне удалить это, а затем добавить его сюда.

136
00:12:01,140 --> 00:12:03,190
Теперь мы можем удалить это тогда,

137
00:12:03,190 --> 00:12:11,070
потому что это тогда не является необходимым для нас, и это закрытие регистра пользователя.

138
00:12:11,070 --> 00:12:12,990
В другой части,

139
00:12:12,990 --> 00:12:16,810
мы будем делать паспорт аутентифицировать местный.

140
00:12:16,970 --> 00:12:19,510
Посмотрите на синтаксис здесь.

141
00:12:19,510 --> 00:12:23,425
Таким образом, это паспорт аутентифицировать локальный, а затем после этого,

142
00:12:23,425 --> 00:12:29,325
мы должны вызвать эту функцию здесь, что параметры req,

143
00:12:29,325 --> 00:12:35,245
res и что третий является функцией обратного вызова здесь.

144
00:12:35,245 --> 00:12:42,275
Таким образом, это так реализуется, потому что паспорт ожидает, что вы сделаете это таким образом.

145
00:12:42,275 --> 00:12:46,495
Здесь мы установим код статуса req res 200,

146
00:12:46,495 --> 00:12:49,930
установите заголовок содержимого приложения json, а затем мы будем

147
00:12:49,930 --> 00:12:59,410
res json регистрации статуса успешно, и мы не будем передавать значение пользователя здесь.

148
00:12:59,410 --> 00:13:03,240
Вместо этого, то, что я сделаю, я

149
00:13:03,240 --> 00:13:10,695
установлю флаг, называемый успехом здесь.

150
00:13:10,695 --> 00:13:15,620
Теперь таким образом, на нашей стороне клиента, когда этот json получен,

151
00:13:15,620 --> 00:13:20,550
клиент может просто извлечь свойство успеха, а затем проверить, верно ли это

152
00:13:20,550 --> 00:13:25,695
или нет, чтобы быстро проверить, была ли регистрация успешной или нет.

153
00:13:25,695 --> 00:13:32,000
Так вот, как мы будем обрабатывать процесс регистрации пользователей здесь.

154
00:13:32,000 --> 00:13:35,470
Так что обратите внимание, как код значительно упростился.

155
00:13:35,470 --> 00:13:38,924
Если пользователь не зарегистрировался должным образом,

156
00:13:38,924 --> 00:13:45,665
то это отправит обратно сообщение об ошибке, а также проверка подлинности завершится неудачей.

157
00:13:45,665 --> 00:13:51,115
Таким образом, в обоих случаях вы поймете ситуацию, когда аутентификация пользователя не выполняется.

158
00:13:51,115 --> 00:13:56,270
Теперь сам процесс входа также значительно упрощается.

159
00:13:56,270 --> 00:14:01,650
Таким образом, нам не нужно делать все это в маршруте входа здесь.

160
00:14:01,650 --> 00:14:07,220
Поэтому я собираюсь удалить весь этот код, и этот маршрут входа упрощается здесь.

161
00:14:07,220 --> 00:14:14,365
Теперь для логина путь - для сообщения маршрутизатора, когда мы делаем это здесь,

162
00:14:14,365 --> 00:14:19,150
здесь также мы ожидаем, что имя пользователя и пароль будут включены

163
00:14:19,150 --> 00:14:24,240
в тело сообщения, которое приходит к ней.

164
00:14:24,240 --> 00:14:32,030
В отличие от предыдущего случая, когда мы включали это в заголовок авторизации,

165
00:14:32,030 --> 00:14:37,865
здесь мы ожидаем, что это будет включено в тело входящего сообщения.

166
00:14:37,865 --> 00:14:47,730
Таким образом, чтобы проверить подлинность, мы просто скажем паспорт аутентифицировать, и мы скажем здесь местный.

167
00:14:47,730 --> 00:14:52,320
Так что это будет второй звонок здесь.

168
00:14:52,320 --> 00:14:55,360
Так что это второе промежуточное программное обеспечение, которое мы собираемся сократить.

169
00:14:55,360 --> 00:15:01,690
Поэтому, когда сообщение маршрутизатора приходит на конечной точке входа,

170
00:15:01,690 --> 00:15:06,095
мы сначала вызовем паспорт аутентифицировать локальный.

171
00:15:06,095 --> 00:15:09,660
Если это успешно, то это придет

172
00:15:09,660 --> 00:15:13,485
и следующая функция будет выполнена.

173
00:15:13,485 --> 00:15:15,760
При возникновении какой-либо ошибки при проверке подлинности

174
00:15:15,760 --> 00:15:18,850
этот локальный паспорт автоматически

175
00:15:18,850 --> 00:15:24,210
отсылает клиенту ответ об ошибке проверки подлинности.

176
00:15:24,210 --> 00:15:26,190
Так что об этом уже позаботились.

177
00:15:26,190 --> 00:15:33,345
Поэтому обратите внимание, как код в процессе входа значительно упрощается.

178
00:15:33,345 --> 00:15:36,565
Итак, если это пройдет успешно,

179
00:15:36,565 --> 00:15:42,775
мне нужно только проверить req и res, и здесь, что я буду делать,

180
00:15:42,775 --> 00:15:49,665
я просто отправлю сообщение на клиентскую сторону с этой информацией здесь.

181
00:15:49,665 --> 00:15:53,775
Мы скажем, код состояния res 200,

182
00:15:53,775 --> 00:16:02,145
res установить тип содержимого заголовка приложения json и res json успех true статус.

183
00:16:02,145 --> 00:16:13,010
Скажем, вы успешно вошли в систему.

184
00:16:13,010 --> 00:16:18,100
Вот оно. Это изменение, которое мы собираемся внести в файл users.js.

185
00:16:18,100 --> 00:16:21,275
Так что обратите внимание, как благодаря паспорту пользователя,

186
00:16:21,275 --> 00:16:24,655
как процессу регистрации, так и процессу входа в систему,

187
00:16:24,655 --> 00:16:28,205
код значительно упростился в этом случае.

188
00:16:28,205 --> 00:16:34,465
Теперь мы перейдем к обновлению файла app.js на app.js сейчас.

189
00:16:34,465 --> 00:16:37,555
В app.js прямо здесь

190
00:16:37,555 --> 00:16:50,540
мы введем паспорт.

191
00:16:51,270 --> 00:16:55,310
Затем мы импортируем

192
00:16:59,820 --> 00:17:07,120
модуль аутентификации, который мы только что реализовали.

193
00:17:07,120 --> 00:17:15,390
Мы скажем, var authenticate и в файле app.js ниже здесь после сеанса

194
00:17:15,390 --> 00:17:25,320
мы добавим app.use (pasport.initialize)

195
00:17:25,320 --> 00:17:32,100
и app.use (.session).

196
00:17:32,950 --> 00:17:37,810
Если пользователь вошел в систему,

197
00:17:37,810 --> 00:17:42,945
то происходит то, что когда сеанс инициируется снова,

198
00:17:42,945 --> 00:17:47,095
вы помните, что при входе здесь

199
00:17:47,095 --> 00:17:48,735
вы будете входить здесь,

200
00:17:48,735 --> 00:17:51,705
и вызов паспорта аутентифицировать локальный,

201
00:17:51,705 --> 00:17:53,730
когда это делается на этапе входа в систему,

202
00:17:53,730 --> 00:17:56,460
паспорт аутентифицировать локальный будет

203
00:17:56,460 --> 00:18:00,625
автоматически добавляют свойство пользователя в сообщение запроса.

204
00:18:00,625 --> 00:18:03,415
Таким образом, он добавит req.user, а затем

205
00:18:03,415 --> 00:18:07,265
сеанс паспорта, который мы сделали здесь, автоматически

206
00:18:07,265 --> 00:18:12,575
сериализует эту информацию пользователя, а затем сохранит ее в сеансе.

207
00:18:12,575 --> 00:18:15,925
Итак, и впоследствии, всякий раз, когда

208
00:18:15,925 --> 00:18:19,135
входящий запрос поступает

209
00:18:19,135 --> 00:18:22,630
со стороны клиента с уже установленным файлом cookie сеанса,

210
00:18:22,630 --> 00:18:29,250
это автоматически загрузит req.user во входящий запрос.

211
00:18:29,250 --> 00:18:32,735
Итак, именно так организована сама паспортная сессия.

212
00:18:32,735 --> 00:18:34,445
Таким образом, как только это будет сделано,

213
00:18:34,445 --> 00:18:40,075
даже наш код аутентификации станет намного проще здесь.

214
00:18:40,075 --> 00:18:42,400
Итак, в коде аутентификации

215
00:18:42,400 --> 00:18:49,450
мы просто скажем, если req.user.

216
00:18:49,450 --> 00:18:55,690
Таким образом, req.user будет загружен промежуточным программным обеспечением сеанса паспорта автоматически,

217
00:18:55,690 --> 00:18:58,845
и поэтому мы скажем req.user.

218
00:18:58,845 --> 00:19:03,940
Если не req.user мы скажем var err, новая ошибка,

219
00:19:03,940 --> 00:19:09,495
вы не аутентифицированы, и все эти сообщения здесь.

220
00:19:09,495 --> 00:19:15,410
В противном случае, см. часть else также теперь упрощается.

221
00:19:17,280 --> 00:19:20,010
Скажем еще дальше.

222
00:19:20,010 --> 00:19:27,335
Таким образом, ваш код аутентификации становится намного проще, потому что если req.user отсутствует,

223
00:19:27,335 --> 00:19:31,695
то это означает, что аутентификация не была выполнена правильно,

224
00:19:31,695 --> 00:19:33,345
поэтому вы указываете ошибку.

225
00:19:33,345 --> 00:19:35,470
В противном случае вы прошли проверку подлинности.

226
00:19:35,470 --> 00:19:37,110
Если req.user присутствует, это

227
00:19:37,110 --> 00:19:39,900
означает, что паспорт выполнил аутентификацию, и

228
00:19:39,900 --> 00:19:42,970
пользователь req.user загружается в сообщение запроса,

229
00:19:42,970 --> 00:19:46,410
и поэтому вы можете просто пойти дальше вниз.

230
00:19:46,410 --> 00:19:49,815
Итак, это изменение, которое нам нужно сделать в app.js.

231
00:19:49,815 --> 00:19:57,775
Давайте сохраним все изменения, а затем посмотрим на приложение в Postman.

232
00:19:57,775 --> 00:20:01,385
После сохранения всех изменений перезапустите сервер.

233
00:20:01,385 --> 00:20:02,600
Если сервер запущен,

234
00:20:02,600 --> 00:20:04,700
остановите его и перезапустите сервер.

235
00:20:04,700 --> 00:20:07,680
Позвольте мне запустить сервер.

236
00:20:08,160 --> 00:20:10,450
Как только сервер будет запущен и запущен,

237
00:20:10,450 --> 00:20:13,900
давайте отправимся в Почтальон и сделаем несколько запросов.

238
00:20:13,900 --> 00:20:17,650
Отправляясь в Почтальон, позвольте мне теперь попытаться зарегистрировать нового пользователя,

239
00:20:17,650 --> 00:20:22,120
сделав сообщение о том, что пользователи регистрируют конечную точку.

240
00:20:22,120 --> 00:20:28,485
Когда регистрация размещена,

241
00:20:28,485 --> 00:20:31,850
вы увидите, что в тексте ответного сообщения говорится: «

242
00:20:31,850 --> 00:20:35,805
Успех true» и регистрация статуса успешно.

243
00:20:35,805 --> 00:20:40,430
Таким образом, пользователь успешно зарегистрирован на стороне клиента.

244
00:20:40,430 --> 00:20:44,870
Итак, теперь позвольте мне сделать логин пользователя.

245
00:20:44,870 --> 00:20:50,000
Итак, мы скажем: «Войти», и все равно укажите

246
00:20:50,000 --> 00:20:55,765
имя пользователя и пароль в теле сообщения здесь.

247
00:20:55,765 --> 00:20:58,345
Итак, когда я нажимаю на «Отправить»,

248
00:20:58,345 --> 00:21:02,550
вы сразу заметите, что внизу,

249
00:21:02,550 --> 00:21:05,050
он говорит, успех, правда и статус,

250
00:21:05,050 --> 00:21:09,440
вы вошли в систему, а затем в самом заголовке,

251
00:21:09,440 --> 00:21:13,515
вы увидите set-cookie, который приходит, потому что мы настраиваем сеанс,

252
00:21:13,515 --> 00:21:17,390
а затем вы видите файл cookie на месте.

253
00:21:17,390 --> 00:21:19,465
Когда вы нажимаете на куки,

254
00:21:19,465 --> 00:21:23,875
вы видите идентификатор сеанса прямо там.

255
00:21:23,875 --> 00:21:26,980
Итак, теперь мы успешно вошли в систему.

256
00:21:26,980 --> 00:21:35,630
Давайте отправим запрос в конечную точку Get localhost: 3000 блюд.

257
00:21:35,630 --> 00:21:42,210
Вы видите, что ваш запрос поступил успешно, а затем был отправлен ответ.

258
00:21:42,210 --> 00:21:43,350
Конечно, на данный момент

259
00:21:43,350 --> 00:21:48,330
моя база данных пуста, поэтому она отправляет пустой массив

260
00:21:48,330 --> 00:21:54,530
с сайта сервера, когда я запрашиваю локальный хост: 3000/блюда.

261
00:21:55,050 --> 00:21:58,165
Это прекрасно.

262
00:21:58,165 --> 00:22:00,610
Позвольте мне теперь выйти из системы пользователя.

263
00:22:00,610 --> 00:22:02,995
Итак, когда я выхожу пользователя, теперь

264
00:22:02,995 --> 00:22:10,450
вы заметите, что пользователь вышел из системы, и когда вы нажмете на куки,

265
00:22:10,450 --> 00:22:14,660
вы заметите, что, что куки для localhost уже исчезли.

266
00:22:14,660 --> 00:22:19,245
Итак, теперь, если вы попытаетесь сделать get на localhost: diss,

267
00:22:19,245 --> 00:22:24,910
вы видите, что в ответе говорится, что

268
00:22:24,910 --> 00:22:26,640
вы не аутентифицированы.

269
00:22:26,640 --> 00:22:32,760
Давайте войдем еще раз, сделав сообщение на логине пользователей,

270
00:22:32,760 --> 00:22:36,290
а затем, вы видите, что мы можем успешно войти в этот момент.

271
00:22:36,290 --> 00:22:37,830
Вы также заметили,

272
00:22:37,830 --> 00:22:40,075
что новый файл cookie был настроен здесь.

273
00:22:40,075 --> 00:22:44,480
Затем, если мы сделаем получить на локальном хосте: блюда здесь,

274
00:22:44,480 --> 00:22:46,465
сейчас, это будет успешным.

275
00:22:46,465 --> 00:22:51,624
Поскольку мы используем passport-local mangoose как плагин mongoose,

276
00:22:51,624 --> 00:22:55,790
давайте также пойдем и проверим наш сервер MongoDB, чтобы увидеть, как

277
00:22:55,790 --> 00:23:00,410
информация пользователя фактически хранится в нашем MongoDB.

278
00:23:00,410 --> 00:23:04,880
Итак, в вашем терминале

279
00:23:04,880 --> 00:23:06,970
вы можете открыть пульсацию Mongo,

280
00:23:06,970 --> 00:23:11,775
так что давайте скажем Mongo на терминале, а затем подключимся к нашему серверу MongoDB,

281
00:23:11,775 --> 00:23:16,500
а затем скажем, используйте UniCtract.

282
00:23:16,500 --> 00:23:26,285
Затем мы скажем db.users.find () .pretty (), а затем распечатаем информацию пользователя.

283
00:23:26,285 --> 00:23:31,180
Таким образом, когда вы распечатываете информацию пользователя, как вы видите здесь,

284
00:23:31,180 --> 00:23:35,235
есть один пользователь, который мы зарегистрировали ранее.

285
00:23:35,235 --> 00:23:40,840
Итак, вы увидите, что запись пользователя содержит идентификатор объекта, а затем

286
00:23:40,840 --> 00:23:42,665
имя пользователя ниже здесь, а

287
00:23:42,665 --> 00:23:46,060
флаг администратора, который является ложным, а затем,

288
00:23:46,060 --> 00:23:53,720
также обратите внимание, что вместо хранения самого пароля, что

289
00:23:53,720 --> 00:23:57,515
делает плагин Mongos pasport-local mongoose, он хранит

290
00:23:57,515 --> 00:24:01,865
его значение соли здесь и хэш-значение здесь.

291
00:24:01,865 --> 00:24:08,655
Теперь плагин Mongo делает, так это то, что он будет использовать соль как способ

292
00:24:08,655 --> 00:24:15,990
шифрования пароля и установить хэшированный пароль в этом хэш-поле здесь.

293
00:24:15,990 --> 00:24:17,980
Таким образом, когда вы пытаетесь войти в систему,

294
00:24:17,980 --> 00:24:23,130
он применит то же самое преобразование к входящему паролю,

295
00:24:23,130 --> 00:24:27,330
а затем попытается сопоставить его с этим хэш-значением, которое хранится здесь.

296
00:24:27,330 --> 00:24:29,580
Таким образом, вы можете видеть, что в самой базе данных

297
00:24:29,580 --> 00:24:32,855
пароль не хранится непосредственно внутри

298
00:24:32,855 --> 00:24:38,280
хэшированного значения пароля, который хэшируется с помощью этого ключа соли здесь,

299
00:24:38,280 --> 00:24:39,435
который мы видим здесь,

300
00:24:39,435 --> 00:24:42,780
хранится в записи там.

301
00:24:42,780 --> 00:24:47,440
Таким образом, это как паспортно-локальный плагин Mongoose позволяет

302
00:24:47,440 --> 00:24:53,905
нам хранить информацию о пользователе в нашей базе данных.

303
00:24:53,905 --> 00:24:58,680
Благодаря этому быстрому пониманию того, как паспорт, паспорт-локальный

304
00:24:58,680 --> 00:25:02,590
и паспорт-локальный Mongoose помогают нам упростить

305
00:25:02,590 --> 00:25:09,390
локальную стратегию для имени пользователя и пароля в нашем приложении.

306
00:25:09,390 --> 00:25:11,660
Мы завершаем это упражнение.

307
00:25:11,660 --> 00:25:18,390
Это хорошее время для вас сделать Git фиксацию с паспортом сообщения.