1
00:00:03,710 --> 00:00:10,135
Это вторая часть упражнения «Экспресс-сеансы».

2
00:00:10,135 --> 00:00:12,320
Мы завершили первую часть ранее,

3
00:00:12,320 --> 00:00:15,310
где мы добавили поддержку Express

4
00:00:15,310 --> 00:00:20,340
Sessions и используем Express Sessions как способ отслеживания пользователей на стороне сервера

5
00:00:20,340 --> 00:00:24,160
и распознавания входящих запросов от пользователей.

6
00:00:24,160 --> 00:00:30,930
В этом упражнении мы не концентрируемся на самих экспресс-сессиях,

7
00:00:30,930 --> 00:00:36,605
но мы рассмотрим способ расширения нашего экспресс-сервера REST API

8
00:00:36,605 --> 00:00:42,435
для поддержки новой модели регистрации и аутентификации пользователей.

9
00:00:42,435 --> 00:00:48,635
Итак, мы представим новую пользовательскую модель и схему в нашем приложении. У

10
00:00:48,635 --> 00:00:52,295
нас уже есть маршрут пользователей косой черты, который

11
00:00:52,295 --> 00:00:57,290
экспресс-генератор уже смонтировал маршрутизатор пользователя.

12
00:00:57,290 --> 00:01:00,035
Итак, мы собираемся использовать это, а затем обновить

13
00:01:00,035 --> 00:01:03,205
его для поддержки регистрации новых пользователей,

14
00:01:03,205 --> 00:01:05,390
аутентификации существующего пользователя,

15
00:01:05,390 --> 00:01:11,695
а также выхода пользователя с нашего сайта сервера.

16
00:01:11,695 --> 00:01:17,915
Итак, мы рассмотрим Express Sessions как способ отслеживания пользователей после входа пользователя в систему,

17
00:01:17,915 --> 00:01:19,820
а затем, когда пользователь выходит из системы,

18
00:01:19,820 --> 00:01:22,680
сеанс будет удален из системы.

19
00:01:22,680 --> 00:01:27,480
Итак, как мы будем делать это расширение в этом упражнении?

20
00:01:27,480 --> 00:01:29,700
Пойдем и выясним.

21
00:01:29,800 --> 00:01:35,485
Продолжая наш экспресс-REST API сервер,

22
00:01:35,485 --> 00:01:41,835
давайте теперь перейдем к моделям и добавим новый файл с именем user.js.

23
00:01:41,835 --> 00:01:46,440
Это файл, в котором мы создадим пользовательскую схему и модель.

24
00:01:46,440 --> 00:01:51,405
Мы создадим простую схему пользователя, которая отслеживает имя пользователя и пароль,

25
00:01:51,405 --> 00:01:55,520
а также флаг, который установлен, чтобы указать,

26
00:01:55,520 --> 00:01:59,540
является ли пользователь администратором или обычным пользователем.

27
00:01:59,540 --> 00:02:03,660
Таким образом, это один из способов различения между различными типами пользователей.

28
00:02:03,660 --> 00:02:07,210
Итак, в этом файле

29
00:02:07,210 --> 00:02:16,510
давайте сначала требуем Mongoose, потому что мы создаем схему Mongoose,

30
00:02:16,510 --> 00:02:26,710
а затем мы создадим схему с именем Mongoose,

31
00:02:26,710 --> 00:02:29,720
а затем мы скажем var user.

32
00:02:29,720 --> 00:02:32,870
Так что это пользовательская схема, которую мы собираемся создать,

33
00:02:32,870 --> 00:02:38,150
и мы скажем новую схему пользователя.

34
00:02:38,150 --> 00:02:42,740
Схема пользователя будет определена, как я только что упомянул,

35
00:02:42,740 --> 00:02:47,705
с тремя полями здесь называемыми username,

36
00:02:47,705 --> 00:02:55,755
которые, очевидно, будут иметь строку типа,

37
00:02:55,755 --> 00:02:59,290
и это обязательное поле,

38
00:02:59,290 --> 00:03:03,975
и это уникальное поле.

39
00:03:03,975 --> 00:03:07,580
Вы не хотите, чтобы два пользователя с одинаковым именем пользователя в вашей системе,

40
00:03:07,580 --> 00:03:12,810
поэтому мы создаем имя пользователя, а затем второе поле - поле пароля.

41
00:03:12,810 --> 00:03:15,259
Теперь, конечно, вы можете расширить

42
00:03:15,259 --> 00:03:19,820
эту схему пользователя, чтобы позволить пользователю отслеживать весь свой профиль,

43
00:03:19,820 --> 00:03:23,985
но мы сделаем это в одном из последующих упражнений, на данный момент

44
00:03:23,985 --> 00:03:30,604
пользователь распознается в системе просто именем пользователя и паролем.

45
00:03:30,604 --> 00:03:36,290
Таким образом, пароль имеет строку типа, а затем является обязательным.

46
00:03:37,300 --> 00:03:44,320
Третье поле, которое я собираюсь использовать, называется admin.

47
00:03:44,320 --> 00:03:48,025
Таким образом, администратор имеет тип Boolean,

48
00:03:48,025 --> 00:03:58,270
и мы скажем по умолчанию false.

49
00:03:58,270 --> 00:04:02,905
Таким образом, по умолчанию при создании пользователя создается

50
00:04:02,905 --> 00:04:04,830
новый пользователь,

51
00:04:04,830 --> 00:04:06,855
флаг администратора будет установлен в false.

52
00:04:06,855 --> 00:04:09,925
Вы можете явно установить его в true из

53
00:04:09,925 --> 00:04:14,605
вашего кода, чтобы пометить пользователя как административного пользователя.

54
00:04:14,605 --> 00:04:18,460
Возможно, вы можете предоставить дополнительные привилегии администратору

55
00:04:18,460 --> 00:04:21,230
или, возможно, разрешить администратору выполнять

56
00:04:21,230 --> 00:04:24,810
определенные операции, которые обычные пользователи не будут делать этого.

57
00:04:24,810 --> 00:04:27,760
Мы рассмотрим, что в одном из последующих упражнений,

58
00:04:27,760 --> 00:04:31,500
на данный момент, это пользовательская схема, которую мы создали,

59
00:04:31,500 --> 00:04:38,150
давайте создадим из этого модуля модуль и экспортируем из

60
00:04:38,150 --> 00:04:47,075
этого модуля модель Mongoose имени пользователя.

61
00:04:47,075 --> 00:04:51,115
Итак, это модель Mongoose, а схема -

62
00:04:51,115 --> 00:04:55,840
пользовательская схема, которую мы только что определили немного раньше.

63
00:04:55,840 --> 00:05:00,615
Итак, вот как мы определяем нашу пользовательскую схему.

64
00:05:00,615 --> 00:05:03,770
Итак, теперь, когда мы определили нашу пользовательскую схему,

65
00:05:03,770 --> 00:05:08,660
давайте перейдем в маршрутизатор, который уже был настроен

66
00:05:08,660 --> 00:05:15,610
экспресс-генератором, когда он генерирует это экспресс-приложение.

67
00:05:15,610 --> 00:05:17,775
Итак, если вы заходите в папку маршрутов,

68
00:05:17,775 --> 00:05:20,890
вы увидите этот файл под названием users.js.

69
00:05:20,890 --> 00:05:26,780
Таким образом, этот файл users.js будет расширен для создания маршрутизатора.

70
00:05:26,780 --> 00:05:36,720
Итак, прямо там, что я собираюсь сделать, это импортировать body-парсер,

71
00:05:41,510 --> 00:05:46,395
а затем они объявят экспресс-маршрутизатор,

72
00:05:46,395 --> 00:05:50,145
а затем мы скажем также импортировать

73
00:05:50,145 --> 00:05:57,100
пользовательскую схему и

74
00:05:57,100 --> 00:06:03,420
модель от пользователя моделей,

75
00:06:03,950 --> 00:06:09,220
а затем для экспресс-маршрутизатора мы скажем,

76
00:06:09,220 --> 00:06:13,380
маршрутизатор использует анализатор тела.

77
00:06:16,190 --> 00:06:20,690
Итак, теперь, когда мы объявили парсер тела там,

78
00:06:20,690 --> 00:06:23,650
мы собираемся оставить эту часть как таковая,

79
00:06:23,650 --> 00:06:28,040
позже мы изменим это, чтобы позволить администратору

80
00:06:28,040 --> 00:06:30,470
иметь возможность получить

81
00:06:30,470 --> 00:06:33,750
всех пользователей, которые зарегистрированы в системе, но на данный момент,

82
00:06:33,750 --> 00:06:37,705
мы собираемся оставить этот маршрут как таковой.

83
00:06:37,705 --> 00:06:40,500
Мы добавим здесь еще несколько маршрутов,

84
00:06:40,500 --> 00:06:42,965
так что скажем: «Сообщение маршрутизатора».

85
00:06:42,965 --> 00:06:49,970
Таким образом, мы будем поддерживать пост-операцию на маршруте, называемом

86
00:06:49,970 --> 00:06:55,790
signup, и, как вы ожидаете,

87
00:06:55,790 --> 00:07:04,920
этот маршрут регистрации позволит пользователю зарегистрироваться в системе, так что это будет поддерживать регистрацию пользователя.

88
00:07:04,920 --> 00:07:08,355
Итак, мы скажем: «Рек, рес, следующий».

89
00:07:08,355 --> 00:07:16,090
Таким образом, это будет регистрация роутера после регистрации,

90
00:07:16,590 --> 00:07:23,410
остальные методы не будут разрешены в конечной части регистрации.

91
00:07:23,410 --> 00:07:25,865
Таким образом, чтобы получить доступ к

92
00:07:25,865 --> 00:07:31,420
этому, поскольку этот маршрутизатор пользователей установлен на косой черты пользователей,

93
00:07:31,420 --> 00:07:35,645
мы бы указывали эту конечную точку как косая черта пользователей регистрации,

94
00:07:35,645 --> 00:07:41,765
и это конечная точка, которая будет использоваться для регистрации новых пользователей в системе.

95
00:07:41,765 --> 00:07:45,080
Итак, первое, что мы будем делать, это использовать

96
00:07:45,080 --> 00:07:53,300
пользовательский метод, и ожидание заключается в том, что для пользователя, чтобы зарегистрироваться,

97
00:07:53,300 --> 00:07:58,145
имя пользователя и пароль будут предоставлены в виде строки JSON

98
00:07:58,145 --> 00:08:03,185
внутри тела входящего почтового запроса.

99
00:08:03,185 --> 00:08:05,160
Итак, из тела,

100
00:08:05,160 --> 00:08:09,200
поскольку тело уже было бы проанализировано парсером тела,

101
00:08:09,200 --> 00:08:10,370
поэтому из тела

102
00:08:10,370 --> 00:08:13,920
сначала проверит, чтобы убедиться, что

103
00:08:13,920 --> 00:08:22,130
пользователь с этим именем пользователя не существует в системе.

104
00:08:22,130 --> 00:08:24,380
Если пользователь с этим именем пользователя существует,

105
00:08:24,380 --> 00:08:26,900
вы пытаетесь зарегистрировать дублирующегося пользователя

106
00:08:26,900 --> 00:08:29,715
, и это не должно быть разрешено в системе.

107
00:08:29,715 --> 00:08:37,340
Итак, мы скажем: «Пользователи находят одного», а затем попытаемся найти,

108
00:08:37,340 --> 00:08:41,090
есть ли один пользователь с именем пользователя,

109
00:08:41,090 --> 00:08:45,405
выбранным клиентом, который пытается зарегистрировать нового пользователя.

110
00:08:45,405 --> 00:08:47,020
Если пользователь уже существует,

111
00:08:47,020 --> 00:08:51,850
то, очевидно, вы не позволите новому пользователю зарегистрироваться с тем же именем пользователя.

112
00:08:51,850 --> 00:08:55,665
Итак, мы скажем: «Тогда пользователь».

113
00:08:55,665 --> 00:09:03,295
Таким образом, это вернет пользователя здесь и внутри этого пользовательского поля,

114
00:09:03,295 --> 00:09:09,080
тогда мы проверим, существует ли пользователь,

115
00:09:09,080 --> 00:09:12,350
а затем позвольте мне поймать ошибку здесь.

116
00:09:12,350 --> 00:09:19,140
Итак, мы скажем: «Лови ошибку», а затем «Следующая ошибка».

117
00:09:19,140 --> 00:09:26,160
Итак, мы просто передадим это обработчику ошибок там.

118
00:09:26,160 --> 00:09:33,345
Итак, если этот поиск для пользователя возвращает поле пользователя,

119
00:09:33,345 --> 00:09:40,460
если пользователь не равен нулю.

120
00:09:40,460 --> 00:09:45,170
Таким образом, если пользователь, возвращаемый этим поиском,

121
00:09:45,170 --> 00:09:50,510
не является нулевым, то это означает, что пользователь с данным именем пользователя уже существует,

122
00:09:50,510 --> 00:09:53,420
поэтому вы не должны допускать повторную регистрацию.

123
00:09:53,420 --> 00:09:58,765
Так что мы скажем: «Вар ошибается новая ошибка».

124
00:09:58,765 --> 00:10:09,075
И мы скажем: «Пользователь req. body username».

125
00:10:09,075 --> 00:10:15,410
Уже существует. Таким образом, в основном

126
00:10:15,410 --> 00:10:20,565
вы предотвращаете регистрацию дублирующего пользователя, а затем мы скажем

127
00:10:20,565 --> 00:10:29,280
err.status 403 против запрещенного, а затем выходите,

128
00:10:29,280 --> 00:10:33,735
вызывая обработчик ошибок, следующий ошибка. В

129
00:10:33,735 --> 00:10:36,880
противном случае это означает, что пользователь не существует,

130
00:10:36,880 --> 00:10:39,670
поэтому вы должны разрешить пользователю быть подписаны.

131
00:10:39,670 --> 00:10:41,950
Итак, в части else,

132
00:10:41,950 --> 00:10:46,150
скажем, верните user.create ().

133
00:10:47,200 --> 00:10:56,165
Мы создадим нового пользователя с именем пользователя, установленным в req.body.username,

134
00:10:56,165 --> 00:11:02,555
а затем позвольте мне поместить это в следующую строку, чтобы это было более понятным для вас,

135
00:11:02,555 --> 00:11:09,620
и мы скажем пароль: req.body.password.

136
00:11:09,620 --> 00:11:14,550
Теперь мы уже знаем, что флаг администратора по умолчанию будет установлен в false,

137
00:11:14,550 --> 00:11:17,700
поэтому мы собираемся оставить его как таковой,

138
00:11:17,730 --> 00:11:28,175
и это позволит нашему новому пользователю зарегистрироваться, и когда новый пользователь зарегистрирован,

139
00:11:28,175 --> 00:11:37,880
это вернет обещание и внутри «тогда» мы будем обрабатывать это обещание здесь.

140
00:11:37,880 --> 00:11:41,460
Итак, это вернет обещание от

141
00:11:41,460 --> 00:11:45,625
этого «тогда», а затем мы справимся с этим в следующем «тогда» здесь.

142
00:11:45,625 --> 00:12:02,120
Скажем тогда, res.statusCode 200,

143
00:12:02,120 --> 00:12:10,640
res.SetHeader, и мы скажем, контент-тип приложения/json,

144
00:12:19,830 --> 00:12:38,000
и мы скажем, res.json (статус: Регистрация Успешная)

145
00:12:42,960 --> 00:12:45,760
, и если вы хотите,

146
00:12:45,760 --> 00:12:49,659
мы можем загрузить пользователя в

147
00:12:49,659 --> 00:12:58,270
это ответное сообщение здесь как свойство в json.

148
00:13:02,790 --> 00:13:06,890
Будет сказано, что регистрация прошла успешно.

149
00:13:07,830 --> 00:13:14,950
Тогда, если есть ошибка в

150
00:13:14,950 --> 00:13:22,790
этой операции, будет говорить «next err».

151
00:13:22,790 --> 00:13:25,200
Таким образом, это обработает ошибку.

152
00:13:25,440 --> 00:13:29,220
Если обещание не разрешится успешно,

153
00:13:29,220 --> 00:13:32,020
то будет обработано этим. Так вот и всё.

154
00:13:32,020 --> 00:13:36,150
Итак, здесь у нас есть способ для пользователя зарегистрироваться.

155
00:13:36,150 --> 00:13:38,280
Таким образом, для того, чтобы пользователь зарегистрировался,

156
00:13:38,280 --> 00:13:46,570
пользователь будет делать сообщение в/users/signup, а в теле сообщения

157
00:13:46,570 --> 00:13:51,810
клиент будет включать строку json

158
00:13:51,810 --> 00:13:57,760
с именем пользователя и свойствами пароля в этой строке json.

159
00:13:57,760 --> 00:14:01,200
Вот как вы регистрируетесь для нового пользователя.

160
00:14:01,200 --> 00:14:06,135
Теперь давайте посмотрим, как мы будем входить в систему пользователя.

161
00:14:06,135 --> 00:14:14,605
Теперь мы по-прежнему будем использовать экспресс-сеансы, которые мы сделали ранее, чтобы отслеживать пользователя.

162
00:14:14,605 --> 00:14:24,270
Таким образом, для регистрации пользователь скажет «router.post» в конечной точке/логине.

163
00:14:24,820 --> 00:14:29,370
Таким образом, на конечной точке /login

164
00:14:32,280 --> 00:14:35,800
мы сделаем router.post.

165
00:14:35,800 --> 00:14:42,460
Мы, очевидно, вместо того, чтобы говорить функцию,

166
00:14:42,460 --> 00:14:48,575
вы можете использовать функцию стрелки здесь для router.post,

167
00:14:48,575 --> 00:14:50,780
я собираюсь сделать то же самое здесь.

168
00:14:50,780 --> 00:14:53,930
Я увлекался функциями стрелок.

169
00:14:53,930 --> 00:14:57,125
Итак, мы сделаем функцию стрелки здесь.

170
00:14:57,125 --> 00:15:00,080
Итак, для входа, как происходит логин?

171
00:15:00,080 --> 00:15:01,880
Поэтому для входа в систему,

172
00:15:01,880 --> 00:15:10,850
что мы будем делать, это то, что мы перейдем к файлу app.js, а затем внутри этого auth,

173
00:15:11,760 --> 00:15:17,050
мы делали эту регистрацию для пользователя там.

174
00:15:17,050 --> 00:15:20,315
То, что я собираюсь сделать, так это я собираюсь скопировать

175
00:15:20,315 --> 00:15:25,730
все это, потому что я бы не стал делать все это в любом случае.

176
00:15:25,730 --> 00:15:32,970
Итак, позвольте мне скопировать весь путь с этого момента до req.session.user.

177
00:15:32,970 --> 00:15:36,925
Итак, если часть req.session.user я собираюсь скопировать,

178
00:15:36,925 --> 00:15:44,120
а затем перейти к users.js и для входа в систему.

179
00:15:44,120 --> 00:15:47,305
Это именно то, как я собираюсь сделать аутентификацию.

180
00:15:47,305 --> 00:15:51,025
Поэтому мы скажем, если не req.session.user.

181
00:15:51,025 --> 00:15:55,965
Таким образом, это означает, что пользователь еще не аутентифицировал себя.

182
00:15:55,965 --> 00:15:59,420
Затем вы ожидаете, что обычная проверка подлинности

183
00:15:59,420 --> 00:16:02,780
в качестве механизма для использования пользователем для проверки подлинности.

184
00:16:02,780 --> 00:16:07,890
Поэтому мы скажем var AuthHeader, если! AuthHeader, то мы поднимем ошибку, в

185
00:16:07,890 --> 00:16:17,760
противном случае мы получим имя пользователя и пароль из заголовка.

186
00:16:17,760 --> 00:16:25,235
Теперь, здесь мы делали, если имя пользователя равно admin и пароль равен паролю.

187
00:16:25,235 --> 00:16:30,535
Но теперь, что мы собираемся сделать, это мы будем искать в

188
00:16:30,535 --> 00:16:36,695
базе данных, чтобы увидеть, существует ли этот конкретный пользователь.

189
00:16:36,695 --> 00:16:39,595
Итак, вместо этого делать здесь,

190
00:16:39,595 --> 00:16:42,995
вместо того, чтобы делать это, если имя пользователя и пароль,

191
00:16:42,995 --> 00:16:48,380
мы скажем, user.findone,

192
00:16:49,650 --> 00:16:56,020
и мы скажем, имя пользователя является именем пользователя.

193
00:16:56,020 --> 00:17:00,730
Таким образом, это свойство равно этому имени пользователя, которое мы только что получили,

194
00:17:00,730 --> 00:17:06,820
а затем мы скажем, тогда пользователь.

195
00:17:09,770 --> 00:17:18,600
Так что внутри этого «тогда».

196
00:17:18,600 --> 00:17:23,110
Поэтому я собираюсь переместить этот код внутри этого «тогда», потому

197
00:17:23,110 --> 00:17:28,395
что теперь то, что я собираюсь проверить, теперь, когда я получил пользователя,

198
00:17:28,395 --> 00:17:35,625
мне нужно проверить, чтобы убедиться, что этот пользователь именно то, что я ищу.

199
00:17:35,625 --> 00:17:37,405
Поэтому на этом этапе

200
00:17:37,405 --> 00:17:42,485
мы собираемся сначала проверить, чтобы убедиться, что пользователь не является нулевым.

201
00:17:42,485 --> 00:17:49,915
Таким образом, мы скажем, если пользователь равен нулю.

202
00:17:49,915 --> 00:17:51,390
Итак, если пользователь равен нулю, это

203
00:17:51,390 --> 00:17:55,930
означает, что мы не смогли найти пользователя с этим конкретным именем пользователя.

204
00:17:55,930 --> 00:17:59,860
Таким образом, вам нужно будет вернуть ошибку здесь.

205
00:17:59,860 --> 00:18:04,540
Поэтому позвольте мне просто скопировать эту часть, а затем вставить ее

206
00:18:04,540 --> 00:18:09,840
здесь, а затем мы вернемся, говоря var new Error,

207
00:18:09,840 --> 00:18:14,575
и мы скажем,

208
00:18:14,575 --> 00:18:23,120
имя пользователя пространства

209
00:18:23,580 --> 00:18:28,750
не существует.

210
00:18:28,750 --> 00:18:30,600
Поэтому в этом случае

211
00:18:30,600 --> 00:18:35,230
этот пользователь не существует, поэтому я просто собираюсь удалить эту часть, а

212
00:18:35,230 --> 00:18:41,840
затем соответствующий статус ошибки будет 403 здесь.

213
00:18:42,450 --> 00:18:44,960
Итак, это первая часть.

214
00:18:44,960 --> 00:18:55,000
Если пользователь равен нулю, то мы, очевидно, собираемся сказать, что пользователь не существует.

215
00:18:55,000 --> 00:19:03,780
Вторая часть, которую мы собираемся проверить, - Else если пароль пользователя.

216
00:19:03,780 --> 00:19:06,800
Таким образом, это означает, что пользователь существует в данный момент.

217
00:19:06,800 --> 00:19:12,420
Итак, вторая проверка, которую мы сделаем, заключается в том, что пароль пользователя не

218
00:19:12,420 --> 00:19:22,330
равен паролю.

219
00:19:22,330 --> 00:19:25,090
Нам снова нужно указать ошибку там.

220
00:19:25,090 --> 00:19:28,820
Таким образом, ошибка будет заключаться

221
00:19:29,790 --> 00:19:34,570
в том, что в этом случае мы скажем

222
00:19:34,570 --> 00:19:41,390
«ваш пароль неверен».

223
00:19:41,390 --> 00:19:44,085
Итак, это вторая часть.

224
00:19:44,085 --> 00:19:49,650
Таким образом, ваш пароль неверный, а затем последняя часть.

225
00:19:49,650 --> 00:19:52,515
Мы скажем «иначе».

226
00:19:52,515 --> 00:19:59,755
Поэтому позвольте мне отступить этот код.

227
00:19:59,755 --> 00:20:05,775
Итак, иначе, если user.username

228
00:20:05,775 --> 00:20:15,815
является именем пользователя, которое, очевидно, должно быть истинным в этом случае.

229
00:20:15,815 --> 00:20:17,990
Затем вторая часть

230
00:20:17,990 --> 00:20:27,620
user.password равна паролю, который также, очевидно, должен быть правильным в этот момент.

231
00:20:27,620 --> 00:20:29,720
Но в любом случае,

232
00:20:29,720 --> 00:20:38,885
я собираюсь проверить эту проблему здесь, и это еще не произойдет вообще в этом случае.

233
00:20:38,885 --> 00:20:41,695
Итак, к тому времени, когда вы достигнете этой точки,

234
00:20:41,695 --> 00:20:45,410
имя пользователя должно быть

235
00:20:45,410 --> 00:20:48,980
таким же, как имя пользователя и пароль должен быть таким же, как пароль,

236
00:20:48,980 --> 00:20:55,240
но в любом случае я поставил двойную проверку в этот момент, чтобы быть вдвойне уверен.

237
00:20:55,240 --> 00:20:56,590
Затем в этом случае

238
00:20:56,590 --> 00:21:02,765
мы скажем, req.session.user аутентифицирован.

239
00:21:02,765 --> 00:21:05,440
Таким образом, мы установим это на аутентификацию,

240
00:21:05,440 --> 00:21:16,480
а также этот, мы скажем

241
00:21:16,480 --> 00:21:18,660
res.StatusCode 200.

242
00:21:18,660 --> 00:21:21,870
Таким образом, мы смогли успешно аутентифицировать пользователя.

243
00:21:21,870 --> 00:21:29,030
Итак, мы скажем res.statusCode 200, а затем мы скажем res.SetHeader

244
00:21:30,540 --> 00:21:43,690
Content-Type text plain и

245
00:21:43,690 --> 00:21:51,500
res.end, мы просто отправим сообщение с надписью «Вы аутентифицированы».

246
00:21:53,700 --> 00:22:00,825
Вот оно. Таким образом, это охватывает тогдашнюю часть пользователя Findone.

247
00:22:00,825 --> 00:22:05,360
Итак, во-первых, мы проверяем, что если пользователь равен нулю, это

248
00:22:05,360 --> 00:22:07,410
означает, что мы не смогли найти пользователя,

249
00:22:07,410 --> 00:22:12,025
поэтому мы, очевидно, возвращаем ошибку, говорящую, что имя пользователя не существует.

250
00:22:12,025 --> 00:22:15,195
Если пароль пользователя не совпадает с паролем,

251
00:22:15,195 --> 00:22:16,450
поэтому на данный момент

252
00:22:16,450 --> 00:22:19,150
пользователь существует, но пароль не совпал, поэтому мы скажем:

253
00:22:19,150 --> 00:22:22,640
«Ваш пароль некорректен», а затем, наконец,

254
00:22:22,640 --> 00:22:29,050
мы достигнем этого момента, тогда имя пользователя и пароль должны быть правильно идентифицированы.

255
00:22:29,330 --> 00:22:35,780
Хотя мне не нужна эта проверка, но я просто поместил ее туда, а затем на этот момент,

256
00:22:35,780 --> 00:22:38,680
я установлю req.session.user для

257
00:22:38,680 --> 00:22:41,830
его аутентификации, а затем установлю код состояния на 200, что означает, что вы

258
00:22:41,830 --> 00:22:48,880
успешно смогли аутентифицировать пользователя, а затем вы можете закончить на этом этапе.

259
00:22:48,880 --> 00:22:51,490
Поскольку это то,

260
00:22:51,490 --> 00:22:54,685
я поставлю улов в этот момент,

261
00:22:54,685 --> 00:23:03,845
поэтому мы скажем ошибку catch, и если ошибка возникает,

262
00:23:03,845 --> 00:23:14,560
то я просто передам

263
00:23:14,560 --> 00:23:20,090
ошибку следующему, чтобы обработчик ошибок мог справиться с ошибкой соответствующим образом.

264
00:23:20,090 --> 00:23:24,415
Так что заканчивает этот пользователь Findone.

265
00:23:24,415 --> 00:23:31,020
Теперь это тот случай, когда req.session.user не установлен.

266
00:23:31,020 --> 00:23:32,905
Если это уже установлено,

267
00:23:32,905 --> 00:23:38,095
то это означает, что пользователь уже вошел в систему.

268
00:23:38,095 --> 00:23:40,630
Поэтому в этом случае

269
00:23:40,630 --> 00:23:50,650
другая часть здесь касается ситуации, когда мы установим

270
00:23:50,650 --> 00:23:52,660
StatusCode на 200,

271
00:23:52,660 --> 00:24:12,205
а Content-Type на text/plain, а затем мы скажем:

272
00:24:12,205 --> 00:24:17,680
«Вы уже прошли проверку подлинности».

273
00:24:17,680 --> 00:24:21,910
Итак, если вы достигнете этой другой части,

274
00:24:22,690 --> 00:24:29,060
вы бы пришли сюда, потому что req.session.user уже не является нулевым,

275
00:24:29,060 --> 00:24:32,150
поэтому это

276
00:24:32,150 --> 00:24:34,995
означает, что пользователь уже прошел аутентификацию, поэтому, когда вы

277
00:24:34,995 --> 00:24:38,200
достигнете этой точки, пользователь уже вошел в систему ранее,

278
00:24:38,200 --> 00:24:41,100
поэтому вам не нужно проверять.

279
00:24:41,100 --> 00:24:42,220
Таким образом, вы просто скажете:

280
00:24:42,220 --> 00:24:46,270
«Вы уже прошли проверку подлинности», а затем закончите на этом этапе.

281
00:24:46,270 --> 00:24:54,975
Хорошо. Итак, теперь последний метод, который мы будем реализовывать, - это выход пользователя.

282
00:24:54,975 --> 00:24:59,180
Итак, мы сделаем router.get on /logout.

283
00:24:59,180 --> 00:25:02,170
Вам должно быть интересно, почему мы делаем выход

284
00:25:02,170 --> 00:25:07,000
на выход, а не сообщение, которое мы сделали при входе в систему?

285
00:25:07,000 --> 00:25:11,090
При входе в систему необходимо указать имя пользователя и пароль.

286
00:25:11,090 --> 00:25:14,900
Для выхода из системы вы просто выходите из системы,

287
00:25:14,900 --> 00:25:17,590
поэтому вам не нужно предоставлять какую-либо дополнительную информацию, потому что

288
00:25:17,590 --> 00:25:20,910
сервер уже отслеживает вас на основе

289
00:25:20,910 --> 00:25:30,665
вашего идентификатора сеанса и внутри этого сеанса cookie здесь.

290
00:25:30,665 --> 00:25:32,620
Поэтому нам не

291
00:25:32,620 --> 00:25:38,890
нужно явно отправлять любую дополнительную информацию в теле сообщения.

292
00:25:38,890 --> 00:25:46,120
Поэтому мы скажем, если req.session так, что это означает, что сеанс должен существовать

293
00:25:46,120 --> 00:25:50,070
, в противном случае вы пытаетесь выйти из системы пользователя, который не вошел в систему.

294
00:25:50,070 --> 00:25:52,280
Так что это не имеет смысла.

295
00:25:52,280 --> 00:25:57,490
Теперь сам сеанс предоставляет этот метод,

296
00:25:57,490 --> 00:26:03,415
называемый destroy, и когда вы вызываете метод destroy,

297
00:26:03,415 --> 00:26:07,520
сеанс уничтожается, и информация удаляется с

298
00:26:07,520 --> 00:26:12,945
серверной стороны, относящейся к этому сеансу.

299
00:26:12,945 --> 00:26:16,970
Таким образом, это означает, что если клиент попытается снова отправить

300
00:26:16,970 --> 00:26:19,190
информацию о сеансе, которая хранится в

301
00:26:19,190 --> 00:26:21,430
виде подписанного файла cookie на стороне клиента,

302
00:26:21,430 --> 00:26:22,640
это будет недействительным.

303
00:26:22,640 --> 00:26:27,870
Поэтому нам нужен метод удаления cookie, который хранится на стороне клиента.

304
00:26:27,870 --> 00:26:31,110
Теперь эта операция удалит

305
00:26:31,110 --> 00:26:36,805
информацию о сеансе со стороны сервера, так что сеанс больше не действителен.

306
00:26:36,805 --> 00:26:38,060
Итак, на данный момент

307
00:26:38,060 --> 00:26:45,115
мы скажем req.session.destroy, а затем мы скажем, res.clearCookie.

308
00:26:45,115 --> 00:26:49,640
Таким образом, ClearCookie - это способ попросить клиента

309
00:26:49,640 --> 00:26:54,875
удалить файл cookie, а имя cookie - идентификатор сеанса.

310
00:26:54,875 --> 00:26:56,630
Итак, в предыдущем упражнении

311
00:26:56,630 --> 00:27:00,910
мы видели, что файл cookie хранится с именем идентификатора сеанса на стороне клиента.

312
00:27:00,910 --> 00:27:05,430
Поэтому мы просим клиента удалить этот файл cookie со

313
00:27:05,430 --> 00:27:10,935
стороны клиента в ответном сообщении, а затем мы скажем,

314
00:27:10,935 --> 00:27:16,835
res.redirect, и мы перенаправим его на главную страницу здесь.

315
00:27:16,835 --> 00:27:21,540
Таким образом, это способ перенаправления пользователя для входа на их стандартную страницу,

316
00:27:21,540 --> 00:27:24,790
так, например, домашнюю страницу вашего приложения.

317
00:27:24,790 --> 00:27:31,090
Таким образом, вы будете обрабатывать выход из системы.

318
00:27:31,090 --> 00:27:33,200
Если req.session не существует,

319
00:27:33,200 --> 00:27:35,380
это означает, что вы не вошли в систему,

320
00:27:35,380 --> 00:27:37,310
поэтому нам придется сгенерировать ошибку.

321
00:27:37,310 --> 00:27:38,945
Таким образом, мы скажем var err,

322
00:27:38,945 --> 00:27:46,370
new Error, «Вы не вошли в систему»,

323
00:27:47,100 --> 00:27:52,615
и мы установим статус ошибки в 403,

324
00:27:52,615 --> 00:27:54,760
это запрещенная операция, а

325
00:27:54,760 --> 00:28:01,060
затем генерируем ошибку в обработчике ошибок, вот и все.

326
00:28:01,060 --> 00:28:08,830
Итак, теперь вы видите, что мы расширили маршрутизатор пользователя для поддержки трех новых конечных точек,

327
00:28:08,830 --> 00:28:13,330
конечной точки регистрации, которая позволяет пользователю зарегистрироваться,

328
00:28:13,330 --> 00:28:17,785
конечной точки входа, которая позволяет зарегистрированному пользователю

329
00:28:17,785 --> 00:28:24,730
войти в систему, а затем конечной точки выхода, которая позволяет зарегистрированному пользователю выйти из системы.

330
00:28:24,730 --> 00:28:26,970
В процессе выхода из системы

331
00:28:26,970 --> 00:28:29,340
вы уничтожаете сеанс на стороне сервера,

332
00:28:29,340 --> 00:28:31,890
вы также очищаете файл cookie на стороне клиента,

333
00:28:31,890 --> 00:28:40,350
так что клиент не может быть использован в истекшем сеансе, чтобы попытаться связаться с этим сервером.

334
00:28:40,350 --> 00:28:43,480
Одно незначительное исправление в users.js,

335
00:28:43,480 --> 00:28:49,225
это должно быть var User require.. /models/user,

336
00:28:49,225 --> 00:28:58,095
помните, что файл users.js находится в папке маршрутов, а затем

337
00:28:58,095 --> 00:29:01,130
файл user.js находится

338
00:29:01,130 --> 00:29:07,440
в папке моделей, которая находится на одном уровне, а затем в папке моделей.

339
00:29:07,440 --> 00:29:11,620
Так что, это должно быть.. /models/user,

340
00:29:11,620 --> 00:29:15,655
поэтому сделайте это незначительное исправление, вот и все.

341
00:29:15,655 --> 00:29:19,040
Мы изменили файл users.js,

342
00:29:19,040 --> 00:29:23,690
теперь последнее, что нам нужно сделать, это пойти и исправить файл app.js.

343
00:29:23,690 --> 00:29:25,965
В файле app.js приложения,

344
00:29:25,965 --> 00:29:29,520
если вы перейдете в файл app.js,

345
00:29:29,520 --> 00:29:31,160
вы увидите, что у нас есть

346
00:29:31,160 --> 00:29:37,240
этот индекс косой черты здесь и косой черты пользователей здесь после проверки подлинности.

347
00:29:37,240 --> 00:29:43,360
Теперь это не сработает для нас, потому что если вам нужно зарегистрироваться,

348
00:29:43,360 --> 00:29:49,140
то пользователь зарегистрируется и войдет в систему до подтверждения авторизации,

349
00:29:49,140 --> 00:29:54,910
в любом случае, если регистрация и вход предназначены для процесса регистрации,

350
00:29:54,910 --> 00:30:04,295
поэтому я собираюсь переместить их до шага аутентификации здесь.

351
00:30:04,295 --> 00:30:09,280
Итак, мы переместим это в это место.

352
00:30:09,280 --> 00:30:15,430
Таким образом, входящий пользователь может получить доступ к индексному файлу

353
00:30:15,430 --> 00:30:21,589
в косой черте, а также получить доступ к конечной точке пользователей без проверки подлинности

354
00:30:21,589 --> 00:30:23,205
, но любая другая конечная точка,

355
00:30:23,205 --> 00:30:25,400
пользователь должен быть аутентифицирован,

356
00:30:25,400 --> 00:30:28,665
так что именно так мы настроили это.

357
00:30:28,665 --> 00:30:32,375
Внутри аутентификации функции мы скажем:

358
00:30:32,375 --> 00:30:40,695
«Если не req.session.user», то обратите внимание, что это место,

359
00:30:40,695 --> 00:30:47,980
мы бы не позволили пользователю войти сюда без входа пользователя.

360
00:30:47,980 --> 00:30:50,450
Итак, если не req.session.user,

361
00:30:50,450 --> 00:30:55,170
то мы просто скажем, что вы не аутентифицированы.

362
00:31:03,600 --> 00:31:09,330
Эта аутентификация должна быть выполнена с помощью метода входа в систему здесь.

363
00:31:09,330 --> 00:31:13,510
Итак, я собираюсь удалить всю эту часть здесь.

364
00:31:17,340 --> 00:31:22,285
Итак, мы скажем, если не req.session.user,

365
00:31:22,285 --> 00:31:28,670
мы скажем, что вы не аутентифицированы, и поэтому нам придется отправить фотографию три здесь,

366
00:31:28,670 --> 00:31:31,560
так что это означает, что вы никогда не должны спуститься

367
00:31:31,560 --> 00:31:34,785
в этот момент вообще без входа пользователя.

368
00:31:34,785 --> 00:31:37,575
Итак, мы скажем, что вы не аутентифицированы.

369
00:31:37,575 --> 00:31:41,990
Напомним, что вам нужно аутентифицироваться, выполнив POST

370
00:31:41,990 --> 00:31:47,120
в конечной точке входа пользователей косой черты.

371
00:31:47,120 --> 00:31:50,930
Таким образом, мы скажем, что вы не аутентифицированы, в противном случае,

372
00:31:50,930 --> 00:31:56,175
если req.session.user равен,

373
00:31:56,175 --> 00:32:01,720
напомним, что в функции входа в

374
00:32:01,720 --> 00:32:07,780
users.js мы установили для следующего пользователя сеанса строку, прошедшую проверку подлинности.

375
00:32:07,780 --> 00:32:10,055
Итак, это то, что мы будем проверять.

376
00:32:10,055 --> 00:32:14,355
Скажем, если req.session.user аутентифицирован,

377
00:32:14,355 --> 00:32:21,955
мы скажем далее, иначе вы не аутентифицированы снова.

378
00:32:21,955 --> 00:32:31,990
Тогда мы отправим обратно запрещенное сообщение. Вот оно.

379
00:32:31,990 --> 00:32:33,995
Таким образом, с этим обновлением

380
00:32:33,995 --> 00:32:36,375
мой файл app.js также готов.

381
00:32:36,375 --> 00:32:38,590
Теперь, сделав эти обновления,

382
00:32:38,590 --> 00:32:42,470
давайте пойдем и проверим, как работает наше приложение сейчас.

383
00:32:42,470 --> 00:32:44,350
Переход к терминалу,

384
00:32:44,350 --> 00:32:49,655
если ваш сервер работает, остановите его, а затем перезапустите сервер.

385
00:32:49,655 --> 00:32:51,600
Мой сервер в данный момент не работает,

386
00:32:51,600 --> 00:32:53,405
поэтому я скажу npm start,

387
00:32:53,405 --> 00:32:56,440
и мой сервер должен быть запущен и запущен.

388
00:32:56,440 --> 00:33:00,540
Давайте теперь посмотрим, как мы получим доступ к серверу.

389
00:33:00,540 --> 00:33:04,150
Отправляясь в Почтальон, позвольте мне сделать GET на

390
00:33:04,150 --> 00:33:07,290
localhost: 3000/блюда, а затем вы сразу увидите

391
00:33:07,290 --> 00:33:10,375
, что он жалуется, что вы не аутентифицированы.

392
00:33:10,375 --> 00:33:13,095
Очевидно, я здесь не аутентифицирован.

393
00:33:13,095 --> 00:33:19,560
Позвольте мне попробовать получить доступ только к локальному хосту: 3000, и вы увидите,

394
00:33:19,560 --> 00:33:22,625
что, этот корень доступен для нас.

395
00:33:22,625 --> 00:33:29,850
Теперь, конечно, мы хотим сначала зарегистрировать пользователя, а затем войти в систему

396
00:33:29,850 --> 00:33:37,745
как пользователь, а затем получить доступ к остальным конечным точкам REST API.

397
00:33:37,745 --> 00:33:40,480
Итак, во-первых, позвольте мне зарегистрировать пользователя.

398
00:33:40,480 --> 00:33:41,925
Чтобы зарегистрировать пользователя,

399
00:33:41,925 --> 00:33:51,410
мне нужно сделать POST для локального хоста: 3000/пользователей/регистрация.

400
00:33:53,700 --> 00:33:57,710
Для этого сообщения POST

401
00:33:57,930 --> 00:34:01,635
в теле сообщения

402
00:34:01,635 --> 00:34:07,860
мне нужно включить в тело

403
00:34:07,860 --> 00:34:15,080
сообщения строку JSON с именем пользователя.

404
00:34:15,080 --> 00:34:19,390
Итак, позвольте мне войти в систему, а

405
00:34:19,390 --> 00:34:27,770
затем я просто использую пароль в качестве пароля.

406
00:34:28,810 --> 00:34:31,835
Это действительная регистрация.

407
00:34:31,835 --> 00:34:35,505
Итак, когда я регистрируюсь как пользователь с

408
00:34:35,505 --> 00:34:42,150
этой информацией в виде строки JSON, включенной в тело сообщения,

409
00:34:42,150 --> 00:34:47,590
позвольте мне увидеть, что заголовок теперь содержит приложение типа содержимого,

410
00:34:47,590 --> 00:34:50,440
JSON, потому что я установил JSON в теле

411
00:34:50,440 --> 00:34:54,660
сообщения, а затем отправляю POST в регистрацию.

412
00:34:54,660 --> 00:34:57,175
Затем, когда я отправляю POST на регистрацию,

413
00:34:57,175 --> 00:35:02,460
вы сразу увидите, что возвращается сервером здесь.

414
00:35:02,460 --> 00:35:05,630
Итак, вы видите, что сервер вернулся, сказав:

415
00:35:05,630 --> 00:35:10,205
«Регистрация успешно» и сам,

416
00:35:10,205 --> 00:35:13,485
он дает мне сведения о пользователе здесь.

417
00:35:13,485 --> 00:35:19,340
Итак, это запись, которая существует в моем MongoDB, и

418
00:35:19,340 --> 00:35:25,090
обратите внимание, что тип модели - это тип пользовательской модели, который мы установили.

419
00:35:25,090 --> 00:35:28,300
Таким образом, у нас есть имя пользователя и пароль и

420
00:35:28,300 --> 00:35:33,535
флаг администратора, как вы можете видеть установлен в false по умолчанию.

421
00:35:33,535 --> 00:35:37,285
После того, как мы зарегистрируем пользователя,

422
00:35:37,285 --> 00:35:40,370
этот пользователь теперь является действительным пользователем.

423
00:35:40,370 --> 00:35:45,640
Итак, позвольте мне попробовать снова POST того же пользователя и посмотреть, что произойдет.

424
00:35:45,640 --> 00:35:48,935
Итак, когда я POST того же пользователя, очевидно,

425
00:35:48,935 --> 00:35:50,385
там со стороны сервера,

426
00:35:50,385 --> 00:35:52,840
он отвечает, что этот пользователь уже существует.

427
00:35:52,840 --> 00:35:58,480
Таким образом, вы можете видеть, что мы настроили нашу процедуру регистрации, чтобы не позволить

428
00:35:58,480 --> 00:36:04,580
пользователю дублировать регистрацию с тем же идентификатором пользователя.

429
00:36:04,580 --> 00:36:07,135
Хорошо. Итак, это вторая часть.

430
00:36:07,135 --> 00:36:13,570
Теперь давайте сделаем логин пользователя.

431
00:36:13,570 --> 00:36:15,770
Чтобы сделать логин пользователя,

432
00:36:15,770 --> 00:36:20,400
позвольте мне удалить тип содержимого, а затем я также

433
00:36:20,400 --> 00:36:25,440
удалю тело, потому что для входа, это не требуется.

434
00:36:25,440 --> 00:36:28,200
Итак, я ничего не заполняю в

435
00:36:28,200 --> 00:36:31,790
заголовке, а затем пытаюсь войти, и когда я попытался войти в систему,

436
00:36:31,790 --> 00:36:34,805
он отвечает, говоря, что вы не аутентифицированы.

437
00:36:34,805 --> 00:36:36,175
Ты неавторизован.

438
00:36:36,175 --> 00:36:39,595
Теперь мне нужно войти в систему.

439
00:36:39,595 --> 00:36:42,940
Итак, здесь я могу использовать базовую аутентификацию.

440
00:36:42,940 --> 00:36:46,240
Итак, в базовой аутентификации

441
00:36:46,240 --> 00:36:51,170
я просто собираюсь ввести свое имя пользователя и

442
00:36:51,170 --> 00:36:56,575
пароль, которые я только что зарегистрировал на предыдущем шаге, а затем обновить свой запрос,

443
00:36:56,575 --> 00:37:00,060
а затем выполнить POST при входе в систему.

444
00:37:00,060 --> 00:37:02,400
Итак, когда я делаю POST при входе в систему,

445
00:37:02,400 --> 00:37:06,935
вы видите, что сервер отвечает: «Вы аутентифицированы».

446
00:37:06,935 --> 00:37:08,740
Таким образом, на этом этапе

447
00:37:08,740 --> 00:37:11,400
я могу выполнять

448
00:37:11,400 --> 00:37:16,115
запросы GET, PUT, POST и DELETE на всех остальных конечных точках.

449
00:37:16,115 --> 00:37:26,370
Итак, на данный момент, если я сделаю GET на конечной точке блюд,

450
00:37:28,760 --> 00:37:32,675
вы увидите, что это возвращает

451
00:37:32,675 --> 00:37:39,160
пустое поле, потому что моя база данных в настоящее время пуста.

452
00:37:39,160 --> 00:37:44,370
Позвольте мне очистить авторизацию, а также из заголовка удалить

453
00:37:44,370 --> 00:37:49,575
авторизацию, а затем сделать GET, и это окно инструментов просто отлично.

454
00:37:49,575 --> 00:37:52,480
Итак, вы можете видеть, что теперь я могу

455
00:37:52,480 --> 00:37:56,065
получить доступ к конечным точкам, потому что я вошел в систему.

456
00:37:56,065 --> 00:38:00,040
Итак, теперь позвольте мне сделать выход пользователя.

457
00:38:00,040 --> 00:38:05,910
Итак, скажем, localhost: 3000 и выход из системы.

458
00:38:05,910 --> 00:38:08,875
Обратите внимание также, что в

459
00:38:08,875 --> 00:38:12,290
файлах cookie файл cookie был установлен в идентификаторе сеанса прямо там.

460
00:38:12,290 --> 00:38:17,080
Итак, этот файл cookie существует на моем клиентском сайте.

461
00:38:17,080 --> 00:38:22,715
Итак, теперь позвольте мне выйти из системы, сказав GET localhost: 3000/пользователей/выход.

462
00:38:22,715 --> 00:38:26,580
Итак, когда я делаю выход из пользователя,

463
00:38:26,580 --> 00:38:29,765
вы сразу увидите, что я перенаправлюсь на

464
00:38:29,765 --> 00:38:37,830
эту локальную конечную точку: 3000, а также заметите, что файл cookie исчез.

465
00:38:37,830 --> 00:38:40,140
Итак, когда я смотрю на файлы cookie,

466
00:38:40,140 --> 00:38:42,040
вы видите, что localhost,

467
00:38:42,040 --> 00:38:46,470
файл cookie пропал, потому что с моей серверной стороны, когда я делаю выход,

468
00:38:46,470 --> 00:38:51,495
он отправляет обратно чистый cookie на клиентскую сторону, и поэтому cookie пропал.

469
00:38:51,495 --> 00:38:54,555
Теперь, если я попытаюсь сделать GET

470
00:38:54,555 --> 00:39:02,480
на локальном хосте: 3000/dises,

471
00:39:02,480 --> 00:39:05,899
это не будет работать, потому что я не аутентифицирован.

472
00:39:05,899 --> 00:39:11,610
Таким образом, это демонстрирует вам, как вы можете расширить ваш Express сервер,

473
00:39:11,610 --> 00:39:17,190
чтобы позволить пользователям регистрироваться самостоятельно, а затем разрешить пользователю войти в систему,

474
00:39:17,190 --> 00:39:19,860
а затем выйти из системы.

475
00:39:19,860 --> 00:39:25,520
На стороне сервера вы отслеживаете зарегистрированного пользователя, используя сеанс и используя

476
00:39:25,520 --> 00:39:28,260
cookie на стороне клиента, и когда пользователь

477
00:39:28,260 --> 00:39:31,375
выходит из системы, cookie уничтожается на стороне клиента.

478
00:39:31,375 --> 00:39:34,540
С этим мы завершаем это упражнение.

479
00:39:34,540 --> 00:39:37,390
Это хорошее время для вас, чтобы сделать фиксацию Git,

480
00:39:37,390 --> 00:39:42,420
с сообщением, экспресс-сессии часть вторая.