[MUSIC]
В предыдущем уроке мы узнали об обычной аутентификации.
Мы видели, что при обычной аутентификации клиент должен будет явно продолжать
добавлять в поле авторизации, содержащее имя пользователя и
пароль для каждого запроса, который клиент отправляет на сторону сервера.
Теперь это отлично подходит для простой аутентификации.
Cookies - это еще один механизм, который позволяет вашему серверу
иметь возможность ожидать, что клиент будет хранить некоторую информацию на стороне клиента и
явно включать эту информацию в каждый исходящий запрос.
Таким образом, вместо того, чтобы включать ваше имя пользователя и
пароль в кодировке base-64, как мы делали в обычной аутентификации, используя файлы cookie,
ваш сервер может настроить явную часть информации на стороне клиента,
которая затем будет включена в каждый исходящий запрос со стороны клиента.
Теперь расширяя это дальше, если ваш сервер хочет отслеживать информацию о вашем
клиенте, сервер может явно настроить механизм отслеживания сеанса.
Теперь куки небольшие и не могут хранить много информации там,
и это, конечно, не может быть включено в исходящий запрос.
Файлы cookie могут содержать некоторую основную информацию
в заголовке исходящего запроса от клиента.
Теперь, если мы хотим, чтобы отслеживалось гораздо больше информации о клиенте
на стороне сервера, то экспресс-сеансы позволяют нам это сделать.
Давайте подробнее изучим файлы cookie и
экспресс-сеансы в этом уроке, а
также изучим их далее в упражнениях, которые следуют за этой лекцией.
Итак, что такое HTTP-файлы cookie?
HTTP-файлы cookie, как я уже упоминал, представляют собой небольшую часть данных
, которая отправляется с веб-сервера и хранится на стороне клиента.
Теперь почти все браузеры имеют возможность поддерживать
хранение куки на стороне клиента и автоматически включать их
в запрос при отправке запроса на определенный сервер.
Таким образом, каждый последующий запрос со
стороны клиента будет включать в себя новый заголовок
с файлом cookie в заголовке запроса.
Теперь, очевидно, если вы видели, что популярная пресса получила
там плохую репутацию, это, конечно, не совсем незаслуженно.
Но это выдувается из пропорций, чем то, что на самом деле является истиной.
Так что возьмите все, что вы читали в популярной прессе о печенье и
их плохой репутации с зерном соли.
Cookies очень полезны для того, чтобы сделать много интересного.
И мы можем гарантировать, что куки могут иметь достаточную целостность,
встроенную в них, чтобы они не могли манипулировать кем-либо между ними.
Теперь как работает включение этой настройки cookie в исходящий запрос?
Когда клиент отправляет запрос на сайт сервера,
если клиент аутентифицирован на сайте сервера.
Например, используя обычную аутентификацию,
сервер может взамен настроить файл cookie.
Теперь, чтобы настроить куки на сайте клиента, сервер будет включать в
ответное сообщение заголовок с отправленным заголовком cookie и
фактический куки в заголовке.
Теперь, когда клиент получает ответное сообщение от сервера, содержащего
заголовок Set-Cookie, он установит cookie на стороне клиента.
Таким образом, каждый последующий запрос, идущий со стороны клиента, будет
явно включать поле заголовка, называемое как cookie, и
фактический заголовок, который содержит
в качестве значения, информацию cookie, которая была отправлена сервером в ответном сообщении.
Таким образом, каждое последующее сообщение запроса будет нести этот файл cookie в заголовке.
Таким образом, когда сервер получает это сообщение запроса, он может проверить
файл cookie и предположить, от кого исходит этот запрос.
Таким образом, он может распознать клиента, просматривая информацию о файлах cookie.
Таким образом, в этом случае файлы cookie очень
полезны для отправки информации о авторизации.
Таким образом, в обслуживании, включая имя пользователя и пароль как часть основного
заголовка аутентификации в каждом текущем запросе.
Первый раз, когда вы аутентифицируетесь, вы отправляете свое имя пользователя и пароль
, и сервер настраивает куки на вашей стороне.
Впоследствии вам нужно только включить файл cookie в исходящий запрос.
Теперь куки также могут иметь дату истечения срока действия, связанную с ними.
Таким образом, в этот момент файл cookie будет считаться просроченным и
больше не будет действительным.
Таким образом, это один из способов управления продолжительностью, в течение
которой авторизация действительна.
Как Express поддерживает куки?
Теперь, как мы понимаем, Express использует много промежуточного программного обеспечения.
Это где один из промежуточных устройств, который приходит в называемый парсер cookie,
приходит в наше приложение в восемь.
Куки-парсер позволяет серверу настроить куки в заголовке ответа.
Таким образом, это делается с помощью res.cookie и имя и
определенные значения и параметры, как мы увидим в упражнении позже.
Таким образом, куки, когда они отправляются с клиентской стороны, включенные в это
сообщение запроса, анализируются на стороне Express сервера, используя куки-парсер.
Куки-парсер промежуточного программного обеспечения,
который при установке позволит вам разобрать входящие куки.
И затем эти входящие файлы cookie будут добавлены
в запрос в виде заголовка и могут быть рассмотрены на стороне сервера.
Теперь для того, чтобы защитить подлинность файлов cookie,
сами файлы cookie могут быть подписаны сервером.
Теперь, когда сервер подписывает файл cookie, сервер использует секретный ключ,
который известен только стороне сервера.
Теперь, если вы знаете что-нибудь о компьютерной безопасности, криптографии и
шифровании, тогда вы понимаете, что
означают подписывание и секретные ключи, открытые ключи и все это.
Если вы этого не сделаете, просто достаточно сказать, что секретный ключ - это
определенная строка, которую знает только сервер, и никто другой не знает.
Поэтому, когда сервер шифрует файл cookie, он будет использовать секретный ключ в качестве подписи и
создавать то, что называется кодом проверки подлинности хеш-сообщения.
И включает это в тот файл cookie, который отправляется с сервера на клиентскую сторону.
Этот HMAC, созданный на стороне сервера, может быть выполнен только этим
конкретным сервером, зная, что секретный ключ.
Теперь, поскольку сервер является защищенным ресурсом, поэтому
только сервер будет знать секретный ключ, и поэтому очень легко проверить,
когда подписанный файл cookie отправляется со стороны клиента на сторону сервера.
Поэтому, когда подписанный файл cookie отправляется со стороны клиента на сторону сервера,
файл cookie будет настроен на стороне клиента, а
затем все последующие запросы будут включать этот подписанный файл cookie на стороне клиента.
Теперь промежуточное программное обеспечение синтаксического анализа файлов cookie, которое мы настроили с нашим сервером Express,
уже поддерживает подписанные файлы cookie.
Теперь для этого в синтаксическом анализаторе файлов cookie вы также предоставите секретный ключ
в качестве параметра для синтаксического анализатора файлов cookie при настройке промежуточного программного обеспечения синтаксического анализа файлов cookie.
Таким образом, все файлы cookie будут подписаны соответствующим образом, а затем отправлены.
И когда файл cookie анализируется на стороне сервера во входящем
сообщении запроса, он будет добавлен в сообщение запроса как req.signedCookies.
И тогда у вас может быть конкретное поле, которое вы можете проверить подписанный файл cookie.
Файлы cookie очень полезны для
того, чтобы ваш клиент мог отправлять информацию, в результате чего ваш сервер распознает клиента.
Но, конечно, куки имеют ограничения.
Они имеют фиксированный размер, поэтому они не могут кодировать много информации
о клиенте, которую их сервер может получить из файла cookie.
Файл cookie используется, чтобы просто напомнить серверу о том
, какой клиент отправляет запрос.
Теперь, если вы хотите иметь более сложный механизм для отслеживания информации о
клиенте, то на стороне сервера вы можете настроить то, что называется сеансами.
Теперь сеансы — это общий механизм, который доступен на любых серверах.
В частности, мы рассмотрим сам Express и
как Express поддерживает управление сеансами на стороне сервера.
То, как это работает, заключается в том, что сеанс пользователя настраивается на стороне сервера.
Таким образом, сам этот сеанс представляет собой комбинацию куки и
идентификатора сеанса, а сервер отслеживает информацию,
связанную с этим идентификатором сеанса, или индексируемую этим идентификатором сеанса.
Сама информация о сеансе может иметь любой
объем информации, отслеживаемой на стороне сервера и индексируемой этим файлом cookie.
Поэтому, когда клиент отправляет запрос через сервер, затем из куки
извлекается идентификатор сеанса, который используется в качестве индекса на стороне сервера.
Например,
если вы используете базу данных на стороне сервера, этот индекс будет основным индексом в
этой конкретной базе данных на стороне сервера, которая отслеживает сеансы.
Таким образом, дополнительная информация об этом сеансе может быть получена и
использована вашим сервером для принятия решений о том, как
он обслуживает входящий запрос клиента.
Теперь, по умолчанию, сеансы хранятся в памяти на сайте сервера.
Теперь, очевидно, что это означает, что если ваш сервер перезапущен, ваша память
будет очищена, и поэтому вся информация о сеансе исчезнет полностью.
Таким образом, многие серверы будут прибегать к
использованию некоторой формы постоянного хранилища, где отслеживается информация о сеансе.
Постоянное хранилище на стороне сервера может быть выполнено
через какое-то файловое хранилище.
Или даже использовать тот факт, что у вас уже есть база данных на стороне сервера и
чем хранить информацию о сеансе на стороне сервера.
Например, в самом MongoDB.
Теперь в следующем упражнении мы рассмотрим использование файлового хранилища для
отслеживания информации о сеансе на стороне сервера.
Другим аспектом, на который вам нужно обратить внимание, является тот факт, что если
у вас есть реализация распределенного сервера, когда несколько
серверов выступают в качестве сервера для обслуживания запроса.
Затем сервер распространителя должен иметь доступ к информации о сеансе.
Любой из этих серверов должен иметь доступ к информации о сеансе.
Таким образом, вам понадобится инструмент сеансов распространителя на стороне сервера,
чтобы вы могли поддерживать несколько реплицированных серверов.
Особенно это полезно, когда мы пытаемся обеспечить надежность
работы сервера.
Опять же, мы не будем получать слишком много подробностей о тех, кто находится в этом конкретном
курсе, мы будем полагаться на понимание в основном, как работают экспресс-сессии.
Подход специально к Express и
как поддерживается управление сеансами в Express.
Express использует промежуточное программное обеспечение express-session
, которое поддерживает использование сеансов на сервере Express.
Теперь вы устанавливаете промежуточное программное обеспечение express-sessions.
И в упражнении я собираюсь использовать FileStore
как способ постоянного хранения информации о сеансе.
И поэтому мы также включим модуль узла хранилища сеансов, который
позволяет нам использовать файлы на стороне сервера для отслеживания информации о сеансе.
Мы увидим детали в следующем упражнении.
И затем, как только мы это сделаем, ваш сеанс будет настроен с новым
экспресс-сервером, объявив промежуточное программное обеспечение здесь как сеанс, который принимает
определенный набор параметров в качестве параметра здесь.
Опции включают имя сеанса, поэтому мы дадим идентификатор сеанса для
конкретного сеанса.
И тогда вы также предоставите секрет, секретный ключ, который используется для
кодирования подписанного файла cookie, который будет отправлен на клиентскую сторону.
А затем также дополнительная информация, включая SaveUninitialized,
который будет использоваться флаг, а также флаг перепродажи, который используется.
Мы рассмотрим некоторые детали этих опций на следующем слайде.
Таким образом, все эти опции указаны здесь.
И если вы FileStore в качестве постоянного хранилища для ваших сессий,
то мы объявим, что также в вариантах сеанса там.
Так вот как мы бы создали сеанс на стороне экспресс-сервера
с помощью промежуточного программного обеспечения экспресс-сеанса.
И промежуточное программное обеспечение экспресс-сессии, когда клиент отправляет эту информацию,
это будет проанализировано на стороне сервера, и
это приведет к добавлению свойства, называемого сеансом в объект запроса.
Таким образом, эта информация о сеансе будет доступна в
объекте запроса как req.session.
Таким образом, req.session будет нести дополнительную информацию об этом конкретном сеансе
для этого конкретного клиента.
Теперь, как только этот сеанс, входящий запрос анализируется промежуточным программным обеспечением сеанса,
свойство req.session будет добавлено к
объекту сообщения входящего запроса, который экспресс использует.
Таким образом, после того, как сеанс будет проанализирован, свойство прямого сеанса будет доступно, и
мы можем проверить это тоже, чтобы проверить, какой клиент отправил этот запрос.
Когда они настраивают свой объект сеанса на сайте сервера,
как мы видели, мы можем настроить различные параметры для этого сайта сервера.
Файл cookie, параметры из файла cookie идентификатора сеанса и значение по умолчанию для файла
cookie будут такими, как показано здесь, который является путь: '/',
HttpOnly: true, secure: false, MaxAge: null.
Таким образом, это будет значение по умолчанию файла cookie, который будет храниться в пакете
и отправляться на сторону клиента как подписанный файл cookie.
И это будет включено в каждый входящий запрос с сайта клиента.
Тогда genid - это функция, которая генерирует идентификатор сеанса.
По умолчанию используется UUID самого сервера в качестве общего идентификатора.
Затем флаг перепродажи, если это правда, заставляет сеанс быть сохранен обратно
в хранилище, даже если он не изменен запросом.
Иногда входящий запрос может
содержать необходимость изменения информации о сеансе на стороне сервера.
И поэтому, если информация о сеансе будет изменена, она должна быть постоянной.
Если нет, то вам не нужно его сохранять.
Но если вы установите флаг перепродажи в значение true, даже если информация о сеансе
на сервере не изменена входящим запросом клиента, она все равно будет повторно сохранена.
Следующий флаг, который мы посмотрели, был SaveUninitialized.
Если это верно, он создаст вновь созданный сеанс без каких-либо изменений, которые
будут сохранены в хранилище сеансов.
Теперь мы установим это значение false по умолчанию, что означает, что мы будем
отслеживать только те сеансы, которые авторизованы на сервере.
Теперь секрет, как мы видим, это секретный ключ, который используется для подписи файла cookie,
а само хранилище указывает экземпляр хранилища сеанса, который используется.
По умолчанию используется хранилище памяти.
Вы можете указать хранилище файлов или хранилище Монго для
хранения информации о сеансе и так далее.
Поэтому, как только вы укажете эту информацию для вашего промежуточного программного обеспечения
экспресс-сеанса, сеанс будет соответствующим образом настроен и поэтому будет отслеживаться на стороне сервера.
Каждый запрос клиента будет затем сопоставлен с информацией о сеансе
на стороне сервера, когда клиентский запрос анализируется промежуточным программным обеспечением экспресс-сеанса.
И req.session будет добавлен в объект запроса.
С таким пониманием куки и экспресс-сессий, давайте перейдем
к упражнению, где посмотрим, как мы будем использовать куки в первую очередь.
И тогда мы рассмотрим, как мы будем использовать экспресс-сеансы
в нашем приложении Express REST API, над которым мы работали до сих пор.
[ МУЗЫКА]