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

2
00:00:04,649 --> 00:00:08,820
В предыдущем уроке мы узнали об обычной аутентификации.

3
00:00:08,820 --> 00:00:14,398
Мы видели, что при обычной аутентификации клиент должен будет явно продолжать

4
00:00:14,398 --> 00:00:19,720
добавлять в поле авторизации, содержащее имя пользователя и

5
00:00:19,720 --> 00:00:24,100
пароль для каждого запроса, который клиент отправляет на сторону сервера.

6
00:00:24,100 --> 00:00:27,750
Теперь это отлично подходит для простой аутентификации.

7
00:00:27,750 --> 00:00:33,520
Cookies - это еще один механизм, который позволяет вашему серверу

8
00:00:33,520 --> 00:00:38,700
иметь возможность ожидать, что клиент будет хранить некоторую информацию на стороне клиента и

9
00:00:38,700 --> 00:00:43,370
явно включать эту информацию в каждый исходящий запрос.

10
00:00:43,370 --> 00:00:47,360
Таким образом, вместо того, чтобы включать ваше имя пользователя и

11
00:00:47,360 --> 00:00:53,710
пароль в кодировке base-64, как мы делали в обычной аутентификации, используя файлы cookie,

12
00:00:53,710 --> 00:00:58,130
ваш сервер может настроить явную часть информации на стороне клиента,

13
00:00:58,130 --> 00:01:02,520
которая затем будет включена в каждый исходящий запрос со стороны клиента.

14
00:01:03,750 --> 00:01:08,740
Теперь расширяя это дальше, если ваш сервер хочет отслеживать информацию о вашем

15
00:01:08,740 --> 00:01:15,180
клиенте, сервер может явно настроить механизм отслеживания сеанса.

16
00:01:15,180 --> 00:01:20,720
Теперь куки небольшие и не могут хранить много информации там,

17
00:01:20,720 --> 00:01:25,230
и это, конечно, не может быть включено в исходящий запрос.

18
00:01:25,230 --> 00:01:28,010
Файлы cookie могут содержать некоторую основную информацию

19
00:01:28,010 --> 00:01:31,850
в заголовке исходящего запроса от клиента.

20
00:01:31,850 --> 00:01:37,010
Теперь, если мы хотим, чтобы отслеживалось гораздо больше информации о клиенте

21
00:01:37,010 --> 00:01:42,420
на стороне сервера, то экспресс-сеансы позволяют нам это сделать.

22
00:01:42,420 --> 00:01:45,140
Давайте подробнее изучим файлы cookie и

23
00:01:45,140 --> 00:01:49,260
экспресс-сеансы в этом уроке, а

24
00:01:49,260 --> 00:01:54,380
также изучим их далее в упражнениях, которые следуют за этой лекцией.

25
00:01:56,640 --> 00:01:59,340
Итак, что такое HTTP-файлы cookie?

26
00:01:59,340 --> 00:02:04,070
HTTP-файлы cookie, как я уже упоминал, представляют собой небольшую часть данных

27
00:02:04,070 --> 00:02:07,610
, которая отправляется с веб-сервера и хранится на стороне клиента.

28
00:02:07,610 --> 00:02:12,030
Теперь почти все браузеры имеют возможность поддерживать

29
00:02:12,030 --> 00:02:16,850
хранение куки на стороне клиента и автоматически включать их

30
00:02:16,850 --> 00:02:21,590
в запрос при отправке запроса на определенный сервер.

31
00:02:21,590 --> 00:02:27,127
Таким образом, каждый последующий запрос со

32
00:02:27,127 --> 00:02:32,047
стороны клиента будет включать в себя новый заголовок

33
00:02:32,047 --> 00:02:37,141
с файлом cookie в заголовке запроса.

34
00:02:37,141 --> 00:02:41,668
Теперь, очевидно, если вы видели, что популярная пресса получила

35
00:02:41,668 --> 00:02:45,450
там плохую репутацию, это, конечно, не совсем незаслуженно.

36
00:02:45,450 --> 00:02:52,880
Но это выдувается из пропорций, чем то, что на самом деле является истиной.

37
00:02:52,880 --> 00:02:57,760
Так что возьмите все, что вы читали в популярной прессе о печенье и

38
00:02:57,760 --> 00:03:00,570
их плохой репутации с зерном соли.

39
00:03:00,570 --> 00:03:05,040
Cookies очень полезны для того, чтобы сделать много интересного.

40
00:03:05,040 --> 00:03:09,880
И мы можем гарантировать, что куки могут иметь достаточную целостность,

41
00:03:09,880 --> 00:03:15,070
встроенную в них, чтобы они не могли манипулировать кем-либо между ними.

42
00:03:15,070 --> 00:03:21,640
Теперь как работает включение этой настройки cookie в исходящий запрос?

43
00:03:21,640 --> 00:03:25,060
Когда клиент отправляет запрос на сайт сервера,

44
00:03:25,060 --> 00:03:27,870
если клиент аутентифицирован на сайте сервера.

45
00:03:27,870 --> 00:03:31,040
Например, используя обычную аутентификацию,

46
00:03:31,040 --> 00:03:34,950
сервер может взамен настроить файл cookie.

47
00:03:34,950 --> 00:03:39,120
Теперь, чтобы настроить куки на сайте клиента, сервер будет включать в

48
00:03:39,120 --> 00:03:44,090
ответное сообщение заголовок с отправленным заголовком cookie и

49
00:03:44,090 --> 00:03:46,300
фактический куки в заголовке.

50
00:03:46,300 --> 00:03:50,460
Теперь, когда клиент получает ответное сообщение от сервера, содержащего

51
00:03:50,460 --> 00:03:54,500
заголовок Set-Cookie, он установит cookie на стороне клиента.

52
00:03:54,500 --> 00:03:59,455
Таким образом, каждый последующий запрос, идущий со стороны клиента, будет

53
00:03:59,455 --> 00:04:03,602
явно включать поле заголовка, называемое как cookie, и

54
00:04:03,602 --> 00:04:06,846
фактический заголовок, который содержит

55
00:04:06,846 --> 00:04:13,200
в качестве значения, информацию cookie, которая была отправлена сервером в ответном сообщении.

56
00:04:13,200 --> 00:04:17,880
Таким образом, каждое последующее сообщение запроса будет нести этот файл cookie в заголовке.

57
00:04:17,880 --> 00:04:22,470
Таким образом, когда сервер получает это сообщение запроса, он может проверить

58
00:04:22,470 --> 00:04:28,490
файл cookie и предположить, от кого исходит этот запрос.

59
00:04:28,490 --> 00:04:33,612
Таким образом, он может распознать клиента, просматривая информацию о файлах cookie.

60
00:04:33,612 --> 00:04:38,543
Таким образом, в этом случае файлы cookie очень

61
00:04:38,543 --> 00:04:44,019
полезны для отправки информации о авторизации.

62
00:04:44,019 --> 00:04:48,050
Таким образом, в обслуживании, включая имя пользователя и пароль как часть основного

63
00:04:48,050 --> 00:04:51,220
заголовка аутентификации в каждом текущем запросе.

64
00:04:51,220 --> 00:04:55,120
Первый раз, когда вы аутентифицируетесь, вы отправляете свое имя пользователя и пароль

65
00:04:55,120 --> 00:04:57,140
, и сервер настраивает куки на вашей стороне.

66
00:04:57,140 --> 00:05:02,070
Впоследствии вам нужно только включить файл cookie в исходящий запрос.

67
00:05:02,070 --> 00:05:06,789
Теперь куки также могут иметь дату истечения срока действия, связанную с ними.

68
00:05:06,789 --> 00:05:11,641
Таким образом, в этот момент файл cookie будет считаться просроченным и

69
00:05:11,641 --> 00:05:13,440
больше не будет действительным.

70
00:05:13,440 --> 00:05:16,940
Таким образом, это один из способов управления продолжительностью, в течение

71
00:05:16,940 --> 00:05:20,340
которой авторизация действительна.

72
00:05:20,340 --> 00:05:24,350
Как Express поддерживает куки?

73
00:05:24,350 --> 00:05:28,980
Теперь, как мы понимаем, Express использует много промежуточного программного обеспечения.

74
00:05:28,980 --> 00:05:34,100
Это где один из промежуточных устройств, который приходит в называемый парсер cookie,

75
00:05:34,100 --> 00:05:37,092
приходит в наше приложение в восемь.

76
00:05:37,092 --> 00:05:42,580
Куки-парсер позволяет серверу настроить куки в заголовке ответа.

77
00:05:42,580 --> 00:05:48,350
Таким образом, это делается с помощью res.cookie и имя и

78
00:05:48,350 --> 00:05:54,160
определенные значения и параметры, как мы увидим в упражнении позже.

79
00:05:54,160 --> 00:06:00,160
Таким образом, куки, когда они отправляются с клиентской стороны, включенные в это

80
00:06:00,160 --> 00:06:05,980
сообщение запроса, анализируются на стороне Express сервера, используя куки-парсер.

81
00:06:05,980 --> 00:06:08,383
Куки-парсер промежуточного программного обеспечения,

82
00:06:08,383 --> 00:06:13,400
который при установке позволит вам разобрать входящие куки.

83
00:06:13,400 --> 00:06:17,280
И затем эти входящие файлы cookie будут добавлены

84
00:06:17,280 --> 00:06:22,260
в запрос в виде заголовка и могут быть рассмотрены на стороне сервера.

85
00:06:23,340 --> 00:06:26,580
Теперь для того, чтобы защитить подлинность файлов cookie,

86
00:06:26,580 --> 00:06:30,070
сами файлы cookie могут быть подписаны сервером.

87
00:06:30,070 --> 00:06:35,120
Теперь, когда сервер подписывает файл cookie, сервер использует секретный ключ,

88
00:06:35,120 --> 00:06:38,070
который известен только стороне сервера.

89
00:06:38,070 --> 00:06:42,510
Теперь, если вы знаете что-нибудь о компьютерной безопасности, криптографии и

90
00:06:42,510 --> 00:06:47,210
шифровании, тогда вы понимаете, что

91
00:06:47,210 --> 00:06:49,290
означают подписывание и секретные ключи, открытые ключи и все это.

92
00:06:49,290 --> 00:06:53,990
Если вы этого не сделаете, просто достаточно сказать, что секретный ключ - это

93
00:06:53,990 --> 00:06:59,260
определенная строка, которую знает только сервер, и никто другой не знает.

94
00:06:59,260 --> 00:07:05,505
Поэтому, когда сервер шифрует файл cookie, он будет использовать секретный ключ в качестве подписи и

95
00:07:05,505 --> 00:07:11,081
создавать то, что называется кодом проверки подлинности хеш-сообщения.

96
00:07:11,081 --> 00:07:16,450
И включает это в тот файл cookie, который отправляется с сервера на клиентскую сторону.

97
00:07:16,450 --> 00:07:21,210
Этот HMAC, созданный на стороне сервера, может быть выполнен только этим

98
00:07:21,210 --> 00:07:24,540
конкретным сервером, зная, что секретный ключ.

99
00:07:24,540 --> 00:07:27,950
Теперь, поскольку сервер является защищенным ресурсом, поэтому

100
00:07:27,950 --> 00:07:33,670
только сервер будет знать секретный ключ, и поэтому очень легко проверить,

101
00:07:33,670 --> 00:07:38,320
когда подписанный файл cookie отправляется со стороны клиента на сторону сервера.

102
00:07:38,320 --> 00:07:42,040
Поэтому, когда подписанный файл cookie отправляется со стороны клиента на сторону сервера,

103
00:07:42,040 --> 00:07:44,540
файл cookie будет настроен на стороне клиента, а

104
00:07:44,540 --> 00:07:50,310
затем все последующие запросы будут включать этот подписанный файл cookie на стороне клиента.

105
00:07:50,310 --> 00:07:54,290
Теперь промежуточное программное обеспечение синтаксического анализа файлов cookie, которое мы настроили с нашим сервером Express,

106
00:07:54,290 --> 00:07:56,630
уже поддерживает подписанные файлы cookie.

107
00:07:56,630 --> 00:08:02,480
Теперь для этого в синтаксическом анализаторе файлов cookie вы также предоставите секретный ключ

108
00:08:02,480 --> 00:08:07,120
в качестве параметра для синтаксического анализатора файлов cookie при настройке промежуточного программного обеспечения синтаксического анализа файлов cookie.

109
00:08:07,120 --> 00:08:11,970
Таким образом, все файлы cookie будут подписаны соответствующим образом, а затем отправлены.

110
00:08:11,970 --> 00:08:17,240
И когда файл cookie анализируется на стороне сервера во входящем

111
00:08:17,240 --> 00:08:22,660
сообщении запроса, он будет добавлен в сообщение запроса как req.signedCookies.

112
00:08:22,660 --> 00:08:27,980
И тогда у вас может быть конкретное поле, которое вы можете проверить подписанный файл cookie.

113
00:08:27,980 --> 00:08:30,890
Файлы cookie очень полезны для

114
00:08:30,890 --> 00:08:36,380
того, чтобы ваш клиент мог отправлять информацию, в результате чего ваш сервер распознает клиента.

115
00:08:36,380 --> 00:08:38,490
Но, конечно, куки имеют ограничения.

116
00:08:38,490 --> 00:08:42,370
Они имеют фиксированный размер, поэтому они не могут кодировать много информации

117
00:08:42,370 --> 00:08:47,090
о клиенте, которую их сервер может получить из файла cookie.

118
00:08:47,090 --> 00:08:50,710
Файл cookie используется, чтобы просто напомнить серверу о том

119
00:08:50,710 --> 00:08:53,750
, какой клиент отправляет запрос.

120
00:08:53,750 --> 00:08:58,311
Теперь, если вы хотите иметь более сложный механизм для отслеживания информации о

121
00:08:58,311 --> 00:09:02,889
клиенте, то на стороне сервера вы можете настроить то, что называется сеансами.

122
00:09:02,889 --> 00:09:09,180
Теперь сеансы — это общий механизм, который доступен на любых серверах.

123
00:09:09,180 --> 00:09:11,850
В частности, мы рассмотрим сам Express и

124
00:09:11,850 --> 00:09:17,140
как Express поддерживает управление сеансами на стороне сервера.

125
00:09:17,140 --> 00:09:22,930
То, как это работает, заключается в том, что сеанс пользователя настраивается на стороне сервера.

126
00:09:22,930 --> 00:09:27,430
Таким образом, сам этот сеанс представляет собой комбинацию куки и

127
00:09:27,430 --> 00:09:32,270
идентификатора сеанса, а сервер отслеживает информацию,

128
00:09:32,270 --> 00:09:37,250
связанную с этим идентификатором сеанса, или индексируемую этим идентификатором сеанса.

129
00:09:37,250 --> 00:09:40,500
Сама информация о сеансе может иметь любой

130
00:09:40,500 --> 00:09:45,380
объем информации, отслеживаемой на стороне сервера и индексируемой этим файлом cookie.

131
00:09:45,380 --> 00:09:50,910
Поэтому, когда клиент отправляет запрос через сервер, затем из куки

132
00:09:50,910 --> 00:09:56,130
извлекается идентификатор сеанса, который используется в качестве индекса на стороне сервера.

133
00:09:56,130 --> 00:09:56,964
Например,

134
00:09:56,964 --> 00:10:01,548
если вы используете базу данных на стороне сервера, этот индекс будет основным индексом в

135
00:10:01,548 --> 00:10:05,456
этой конкретной базе данных на стороне сервера, которая отслеживает сеансы.

136
00:10:05,456 --> 00:10:10,486
Таким образом, дополнительная информация об этом сеансе может быть получена и

137
00:10:10,486 --> 00:10:13,761
использована вашим сервером для принятия решений о том, как

138
00:10:13,761 --> 00:10:17,380
он обслуживает входящий запрос клиента.

139
00:10:17,380 --> 00:10:23,900
Теперь, по умолчанию, сеансы хранятся в памяти на сайте сервера.

140
00:10:23,900 --> 00:10:28,870
Теперь, очевидно, что это означает, что если ваш сервер перезапущен, ваша память

141
00:10:28,870 --> 00:10:33,260
будет очищена, и поэтому вся информация о сеансе исчезнет полностью.

142
00:10:33,260 --> 00:10:37,350
Таким образом, многие серверы будут прибегать к

143
00:10:37,350 --> 00:10:42,010
использованию некоторой формы постоянного хранилища, где отслеживается информация о сеансе.

144
00:10:42,010 --> 00:10:45,360
Постоянное хранилище на стороне сервера может быть выполнено

145
00:10:45,360 --> 00:10:47,500
через какое-то файловое хранилище.

146
00:10:47,500 --> 00:10:53,460
Или даже использовать тот факт, что у вас уже есть база данных на стороне сервера и

147
00:10:53,460 --> 00:10:56,170
чем хранить информацию о сеансе на стороне сервера.

148
00:10:56,170 --> 00:10:59,590
Например, в самом MongoDB.

149
00:10:59,590 --> 00:11:05,620
Теперь в следующем упражнении мы рассмотрим использование файлового хранилища для

150
00:11:05,620 --> 00:11:10,000
отслеживания информации о сеансе на стороне сервера.

151
00:11:10,000 --> 00:11:14,450
Другим аспектом, на который вам нужно обратить внимание, является тот факт, что если

152
00:11:14,450 --> 00:11:19,540
у вас есть реализация распределенного сервера, когда несколько

153
00:11:19,540 --> 00:11:24,530
серверов выступают в качестве сервера для обслуживания запроса.

154
00:11:24,530 --> 00:11:28,310
Затем сервер распространителя должен иметь доступ к информации о сеансе.

155
00:11:29,460 --> 00:11:32,470
Любой из этих серверов должен иметь доступ к информации о сеансе.

156
00:11:32,470 --> 00:11:36,480
Таким образом, вам понадобится инструмент сеансов распространителя на стороне сервера,

157
00:11:36,480 --> 00:11:40,780
чтобы вы могли поддерживать несколько реплицированных серверов.

158
00:11:40,780 --> 00:11:45,450
Особенно это полезно, когда мы пытаемся обеспечить надежность

159
00:11:45,450 --> 00:11:46,870
работы сервера.

160
00:11:47,960 --> 00:11:52,630
Опять же, мы не будем получать слишком много подробностей о тех, кто находится в этом конкретном

161
00:11:52,630 --> 00:11:58,190
курсе, мы будем полагаться на понимание в основном, как работают экспресс-сессии.

162
00:11:59,710 --> 00:12:02,080
Подход специально к Express и

163
00:12:02,080 --> 00:12:06,080
как поддерживается управление сеансами в Express.

164
00:12:06,080 --> 00:12:10,240
Express использует промежуточное программное обеспечение express-session

165
00:12:10,240 --> 00:12:14,760
, которое поддерживает использование сеансов на сервере Express.

166
00:12:14,760 --> 00:12:18,110
Теперь вы устанавливаете промежуточное программное обеспечение express-sessions.

167
00:12:18,110 --> 00:12:21,140
И в упражнении я собираюсь использовать FileStore

168
00:12:21,140 --> 00:12:24,470
как способ постоянного хранения информации о сеансе.

169
00:12:24,470 --> 00:12:30,440
И поэтому мы также включим модуль узла хранилища сеансов, который

170
00:12:30,440 --> 00:12:37,305
позволяет нам использовать файлы на стороне сервера для отслеживания информации о сеансе.

171
00:12:37,305 --> 00:12:41,120
Мы увидим детали в следующем упражнении.

172
00:12:41,120 --> 00:12:46,247
И затем, как только мы это сделаем, ваш сеанс будет настроен с новым

173
00:12:46,247 --> 00:12:51,690
экспресс-сервером, объявив промежуточное программное обеспечение здесь как сеанс, который принимает

174
00:12:51,690 --> 00:12:57,390
определенный набор параметров в качестве параметра здесь.

175
00:12:57,390 --> 00:13:02,200
Опции включают имя сеанса, поэтому мы дадим идентификатор сеанса для

176
00:13:02,200 --> 00:13:03,500
конкретного сеанса.

177
00:13:03,500 --> 00:13:07,500
И тогда вы также предоставите секрет, секретный ключ, который используется для

178
00:13:07,500 --> 00:13:12,460
кодирования подписанного файла cookie, который будет отправлен на клиентскую сторону.

179
00:13:12,460 --> 00:13:17,960
А затем также дополнительная информация, включая SaveUninitialized,

180
00:13:19,190 --> 00:13:24,625
который будет использоваться флаг, а также флаг перепродажи, который используется.

181
00:13:24,625 --> 00:13:28,760
Мы рассмотрим некоторые детали этих опций на следующем слайде.

182
00:13:28,760 --> 00:13:31,390
Таким образом, все эти опции указаны здесь.

183
00:13:31,390 --> 00:13:36,945
И если вы FileStore в качестве постоянного хранилища для ваших сессий,

184
00:13:36,945 --> 00:13:42,130
то мы объявим, что также в вариантах сеанса там.

185
00:13:42,130 --> 00:13:47,450
Так вот как мы бы создали сеанс на стороне экспресс-сервера

186
00:13:47,450 --> 00:13:49,510
с помощью промежуточного программного обеспечения экспресс-сеанса.

187
00:13:49,510 --> 00:13:55,540
И промежуточное программное обеспечение экспресс-сессии, когда клиент отправляет эту информацию,

188
00:13:55,540 --> 00:13:58,980
это будет проанализировано на стороне сервера, и

189
00:13:58,980 --> 00:14:04,640
это приведет к добавлению свойства, называемого сеансом в объект запроса.

190
00:14:04,640 --> 00:14:09,460
Таким образом, эта информация о сеансе будет доступна в

191
00:14:09,460 --> 00:14:11,505
объекте запроса как req.session.

192
00:14:11,505 --> 00:14:16,221
Таким образом, req.session будет нести дополнительную информацию об этом конкретном сеансе

193
00:14:16,221 --> 00:14:18,325
для этого конкретного клиента.

194
00:14:18,325 --> 00:14:22,979
Теперь, как только этот сеанс, входящий запрос анализируется промежуточным программным обеспечением сеанса,

195
00:14:22,979 --> 00:14:28,957
свойство req.session будет добавлено к

196
00:14:28,957 --> 00:14:33,447
объекту сообщения входящего запроса, который экспресс использует.

197
00:14:33,447 --> 00:14:40,097
Таким образом, после того, как сеанс будет проанализирован, свойство прямого сеанса будет доступно, и

198
00:14:40,097 --> 00:14:46,165
мы можем проверить это тоже, чтобы проверить, какой клиент отправил этот запрос.

199
00:14:46,165 --> 00:14:50,900
Когда они настраивают свой объект сеанса на сайте сервера,

200
00:14:50,900 --> 00:14:54,760
как мы видели, мы можем настроить различные параметры для этого сайта сервера.

201
00:14:54,760 --> 00:14:59,790
Файл cookie, параметры из файла cookie идентификатора сеанса и значение по умолчанию для файла

202
00:14:59,790 --> 00:15:04,275
cookie будут такими, как показано здесь, который является путь: '/',

203
00:15:04,275 --> 00:15:07,700
HttpOnly: true, secure: false, MaxAge: null.

204
00:15:07,700 --> 00:15:13,450
Таким образом, это будет значение по умолчанию файла cookie, который будет храниться в пакете

205
00:15:13,450 --> 00:15:17,680
и отправляться на сторону клиента как подписанный файл cookie.

206
00:15:17,680 --> 00:15:23,306
И это будет включено в каждый входящий запрос с сайта клиента.

207
00:15:23,306 --> 00:15:28,080
Тогда genid - это функция, которая генерирует идентификатор сеанса.

208
00:15:28,080 --> 00:15:33,830
По умолчанию используется UUID самого сервера в качестве общего идентификатора.

209
00:15:33,830 --> 00:15:38,720
Затем флаг перепродажи, если это правда, заставляет сеанс быть сохранен обратно

210
00:15:38,720 --> 00:15:41,470
в хранилище, даже если он не изменен запросом.

211
00:15:41,470 --> 00:15:44,230
Иногда входящий запрос может

212
00:15:45,580 --> 00:15:50,200
содержать необходимость изменения информации о сеансе на стороне сервера.

213
00:15:50,200 --> 00:15:54,300
И поэтому, если информация о сеансе будет изменена, она должна быть постоянной.

214
00:15:54,300 --> 00:15:56,290
Если нет, то вам не нужно его сохранять.

215
00:15:56,290 --> 00:16:00,454
Но если вы установите флаг перепродажи в значение true, даже если информация о сеансе

216
00:16:00,454 --> 00:16:06,030
на сервере не изменена входящим запросом клиента, она все равно будет повторно сохранена.

217
00:16:06,030 --> 00:16:09,980
Следующий флаг, который мы посмотрели, был SaveUninitialized.

218
00:16:09,980 --> 00:16:14,620
Если это верно, он создаст вновь созданный сеанс без каких-либо изменений, которые

219
00:16:14,620 --> 00:16:16,540
будут сохранены в хранилище сеансов.

220
00:16:16,540 --> 00:16:21,164
Теперь мы установим это значение false по умолчанию, что означает, что мы будем

221
00:16:21,164 --> 00:16:25,008
отслеживать только те сеансы, которые авторизованы на сервере.

222
00:16:25,008 --> 00:16:30,955
Теперь секрет, как мы видим, это секретный ключ, который используется для подписи файла cookie,

223
00:16:30,955 --> 00:16:36,310
а само хранилище указывает экземпляр хранилища сеанса, который используется.

224
00:16:36,310 --> 00:16:39,810
По умолчанию используется хранилище памяти.

225
00:16:39,810 --> 00:16:42,950
Вы можете указать хранилище файлов или хранилище Монго для

226
00:16:42,950 --> 00:16:46,000
хранения информации о сеансе и так далее.

227
00:16:46,000 --> 00:16:51,590
Поэтому, как только вы укажете эту информацию для вашего промежуточного программного обеспечения

228
00:16:51,590 --> 00:16:57,350
экспресс-сеанса, сеанс будет соответствующим образом настроен и поэтому будет отслеживаться на стороне сервера.

229
00:16:57,350 --> 00:17:02,430
Каждый запрос клиента будет затем сопоставлен с информацией о сеансе

230
00:17:02,430 --> 00:17:08,260
на стороне сервера, когда клиентский запрос анализируется промежуточным программным обеспечением экспресс-сеанса.

231
00:17:08,260 --> 00:17:12,960
И req.session будет добавлен в объект запроса.

232
00:17:14,150 --> 00:17:19,010
С таким пониманием куки и экспресс-сессий, давайте перейдем

233
00:17:19,010 --> 00:17:24,050
к упражнению, где посмотрим, как мы будем использовать куки в первую очередь.

234
00:17:24,050 --> 00:17:29,360
И тогда мы рассмотрим, как мы будем использовать экспресс-сеансы

235
00:17:29,360 --> 00:17:35,121
в нашем приложении Express REST API, над которым мы работали до сих пор.

236
00:17:35,121 --> 00:17:40,109
[ МУЗЫКА]