Теперь, когда мы понимаем куки и экспресс-сеансы,
в этом упражнении давайте рассмотрим куки, в частности.
Мы увидим, как мы можем использовать куки-парсер промежуточного программного обеспечения
для настройки и обработки куки в нашем экспресс-приложении.
Возвращаясь к нашему приложению
Extract Server Express, над которым мы работали до сих пор,
вы заметите в верхней части, что куки-парсер
уже включен в наше экспресс-приложение.
Если вам нужно явно установить куки-парсер,
вам просто нужно ввести «npm install куки-парсер минус сохранение».
Но так как наш Express Generator уже включил
куки-парсер в наше экспресс-приложение, которое мы вылетели,
нам не нужно делать этот шаг в этом упражнении.
Итак, вы видите, что куки-парсер уже включен туда,
а затем, если вы прокрутите вниз,
вы увидите, что в коде прямо ниже,
вы увидите, что куки-парсер уже включен в промежуточное программное обеспечение там.
Теперь, для этого куки-парсера,
мы будем использовать подписанные куки в этом упражнении.
Итак, для этого куки-парсера
я собираюсь предоставить секретный ключ в качестве параметра здесь.
Секретным ключом может быть любая строка там,
так что я просто собираюсь поставить строку вроде этой, я скажу 12345-67890.
Это не должно быть ничего значимого,
это просто ключ, который может быть использован
нашим куки-парсером для того, чтобы зашифровать
информацию и подписать куки, которые отправляются с сервера клиенту.
Итак, как только мы настроим наш куки-парсер для обработки подписанных куки,
поэтому в самой авторизации,
так что вы видите, что у нас есть авторизация, которую мы построили здесь.
Теперь, в рамках авторизации,
то, что мы собираемся сделать, это, когда
пользователь впервые попытается получить доступ к серверу,
мы будем ожидать, что пользователь авторизоваться самостоятельно.
После этого мы установим куки на стороне клиента с сервера, а
затем клиент не должен
явно продолжать отправлять основную информацию аутентификации.
Вместо этого клиенту просто нужно будет включить файл cookie в исходящий запрос.
Так как мы используем подписанные куки здесь, поэтому,
когда входящий запрос приходит,
поэтому мы будем обрабатывать это внутри авторизации.
Теперь вы помните, что мы уже установили промежуточное программное обеспечение авторизации здесь.
Таким образом, мы собираемся изменить это промежуточное программное обеспечение авторизации, чтобы использовать
куки вместо заголовка авторизации.
Итак, то, что мы будем делать здесь, это то, что
мы скажем «console.log», а затем
«console.log (req.signedCookies)», чтобы мы увидели, что на самом деле
включено в подписанный файл cookie здесь.
Теперь, также после этого,
мы будем говорить: «Если (! Req.signedCookies.user)».
Пользователь будет свойством, которое мы установим
в подписанном файле cookie, как вы увидите
немного позже, как мы будем настраивать подписанный файл cookie.
Таким образом, если входящий запрос не включает поле пользователя в подписанные куки,
а затем это означает, что пользователь еще не авторизован.
Поэтому в этом случае
мы будем ожидать, что пользователь аутентифицирует себя.
Так что, тогда мы сделаем всю эту часть здесь.
Поэтому обратите внимание, что мы уже делали это
раньше, когда мы обрабатывали заголовок аутентификации.
Итак, мы возьмем всю эту часть,
вплоть до этого «еще» здесь, а затем включим ее внутри.
Итак, по существу, то, что мы указываем здесь, это то, что
позвольте мне отступить.
Как вы видите, я очень особенный в моем отступе
, потому что это делает код более легким для чтения.
Итак, внутри этого if,
так что это конечная точка if этого здесь.
Поэтому мы говорим, если подписанный файл cookie не содержит свойство пользователя на нем,
то мы ожидаем, что пользователь авторизован, включив заголовок авторизации.
Итак, мы будем искать заголовок авторизации.
Если заголовок авторизации недоступен,
то мы просто отклоним пользователя и предложим
пользователю ввести имя пользователя и пароль, как мы делали в предыдущем упражнении.
Если заголовок авторизации включен,
то мы будем обрабатывать заголовок авторизации так же, как мы делали раньше,
и если пользователь является авторизованным пользователем,
напомним, что мы вызвали следующий, чтобы позволить пользователю продолжить вперед.
Теперь на этом этапе,
то, что мы будем делать, мы скажем, что
мы создадим куки на этом этапе.
Так вот где мы будем использовать файл cookie res здесь.
Обратите внимание, что печенье не существует,
поэтому мы скажем «res.cookie».
Как вы можете видеть, сам файл cookie res принимает первую строку имени значения,
строку значения и параметры, параметры cookie.
Установите имя файла cookie значение с заданными параметрами, и параметры включены здесь,
некоторые параметры для файла cookie здесь.
Я собираюсь просто использовать несколько вариантов здесь.
Итак, мы скажем: «res.cookie», а затем я собираюсь настроить файл cookie с именем пользователя.
Теперь обратите внимание, что это причина,
по которой я проверяю req.signedCookies.User там.
Поэтому мы скажем «res.cookie («пользователь»,)» и
поле пользователя, которое я установлю его на «admin», а
затем я настрою это как подписанный файл cookie.
Так что я скажу: «Подписано: правда».
Таким образом, это означает, что мой куки-парсер будет гарантировать
, что этот куки будет подписан и настроен.
Таким образом, это вариант, который я установил для файла cookie res здесь.
Таким образом, это будет включать
это конкретное имя в подписанный файл cookie с этим конкретным значением.
Поэтому я могу проверить это значение здесь.
Поэтому, если этого не существует,
то, конечно, я ожидаю, что пользователь
будет аутентифицироваться, используя базовую аутентификацию, и если обычная аутентификация успешна, я настрою файл cookie здесь и настрою
поле cookie в исходящем ответном сообщении здесь, и
это вызовет для настройки файла cookie на стороне клиента, а затем
все последующие запросы будут включать этот файл cookie в запрос клиента.
Так вот как я обрабатываю тот факт, когда cookie.user не существует.
Там. Если он существует,
то другая часть,
так что это означает, что подписанный файл cookie уже
существует, и свойство пользователя определено на этом,
то в другом
случае я проверю, является ли req.signedCookies.User admin.
Затем это означает, что подписанный файл cookie содержит правильную информацию.
Тогда я скажу следующее.
Таким образом, это означает, что вы разрешите запрос пройти.
В противном случае этот файл cookie недействителен, так как он не содержит этого правильного значения.
Это означает, что это ошибка.
Поэтому в этом случае
мы скажем, что вы не аутентифицированы,
и тогда мы просто вызовем ошибку в этом вопросе.
Теперь мы не собираемся запрашивать пользователя для
сеанса, потому что это должно быть сделано раньше.
Теперь, как правило, этого не произойдет,
потому что если файл cookie уже установлен на стороне клиента,
то он должен включать правильное значение в любом случае.
Но ради полноты
я также включил проверку ошибок else здесь на данный момент. Вот оно.
С помощью этой настройки мы превратили
наше экспресс-приложение в тот, который обрабатывает куки здесь.
Заметьте еще раз, позвольте мне обратить ваше внимание на то, что мы здесь делаем еще раз.
Здесь мы проверяем, чтобы убедиться
, что свойство пользователя в подписанных куки не существует,
или даже подписанный куки сам не существует.
Затем мы будем ожидать, что будет сделано базовое разрешение.
Если авторизация прошла успешно,
я собираюсь настроить файл cookie, используя res.cookie здесь.
Затем все последующие запросы будут нести подписанный файл cookie в любом случае,
а затем я проверю, что подписанный файл cookie является
действительным подписанным файлом cookie и содержит свойство пользователя, которое установлено равным admin.
Если это так, то это авторизованный доступ,
поэтому он позволит продолжить движение вперед.
Если нет, то я поднимаю ошибку на данный момент.
Незначительное исправление, новые версии Node.js ожидают, что вы будете использовать это как
новый buffer.From вместо нового буфера, чтобы справиться с некоторыми проблемами безопасности.
Поэтому просто исправьте эту строку в новый buffer.From. Вот оно.
Давайте сохраним изменения, а затем пойдем и посмотрим на наше приложение в этом Почтальоне.
Если предыдущий сервер запущен,
просто остановите его, введя Control C,
а затем перезапустите сервер, сказав npm start.
Конечно, убедитесь, что ваш сервер MongoDB работает и работает.
В противном случае ваш экспресс-сервер не запустится правильно.
Так что, как только ваш экспресс-сервер запущен,
то пойдем к нашему Почтальон и попробуем подключиться к серверу.
И я продемонстрирую несколько аспектов того, как обрабатываются файлы cookie.
Теперь, отправляясь в почтальон,
позвольте мне прояснить всю эту информацию
от почтальона, а затем мы начнем с основ.
Поэтому позвольте мне попробовать получить доступ к локальному хосту: 3000/блюда.
Теперь, после того, как я все
очищу, я отправлю запрос и сохраню.
И поэтому со стороны сервера
он говорит, что вы не аутентифицированы.
Затем, когда вы смотрите на заголовок,
это просит меня пройти аутентификацию с помощью WWW-Authenticate.
Итак, теперь позвольте мне перейти в авторизацию, а затем настроить базовую авторизацию,
а затем я настрою авторизацию как admin
, а затем пароль, а затем обновить запрос, чтобы заголовок
теперь содержал заголовок авторизации здесь с информацией там.
И затем позвольте мне отправить запрос Git с этой части.
Если я отправлю запрос Git,
то в ответ вы увидите, что запрос Git был успешным.
Обратите внимание также на несколько других вещей.
Вы увидите статус 200 OK.
Обратите внимание также, что файл cookie был установлен на стороне нашего клиента в Postman здесь.
Этот файл cookie содержит информацию.
Посмотрим детали печенья через минуту.
Затем, когда вы смотрите на заголовок,
вы видите в заголовке это значение здесь, говоря Set-Cookie,
а затем эту информацию, которая приходит сюда.
Теперь, если вы внимательно посмотрите на него,
вы увидите что-то здесь говорит, что пользователь равен,
а затем вы видите это значение здесь, admin там.
Итак, вы заметили, что что-то было заключено в куки.
Если вы хотите действительно изучить файл cookie,
перейдите сюда, в Postman, а затем нажмите на эти ключи,
и затем это покажет вам все файлы cookie, которые были настроены на этой стороне клиента.
Тогда, в частности, позвольте мне очистить все эти другие файлы cookie.
Я, вероятно, использовал некоторые из них по какой-то другой причине.
Так что позволь мне просто очистить эти печенья.
В любом случае, если ты их
увидишь, можешь просто оставить их там.
Не большая проблема.
Сосредоточьтесь конкретно на локальном хосте здесь,
а затем вы видите этот файл cookie здесь.
Просто нажмите на файл cookie,
а затем вы увидите фактическое значение внутри файла cookie, который хранится там.
Затем также дата истечения срока действия для этой настройки cookie здесь.
Теперь это значение будет именно то, что вы видели
в наборе cookie, который пришел со стороны сервера.
Теперь это также означает, что в последующих запросах, которые идут,
поэтому, даже если я очищу свою авторизацию,
и даже если я удалю заголовок авторизации,
потому что файл cookie был настроен,
этот файл cookie был настроен на моем локальном хосте,
каждый последующий запрос, поступающий на этот сервер будет включать этот файл cookie.
Поэтому, несмотря на то, что у меня не было бы
настроенных там заголовков, если я отправлю запрос, вы заметите, что запрос Git работает так же, как и прежде, без каких-либо проблем, из-за того, что каждый исходящий запрос будет автоматически включать
этот файл cookie в исходящий запрос от моего Postman Здесь.
Это демонстрирует использование файлов cookie в нашем приложении.
С этим мы видели, как куки могут быть настроены и
обработаны на нашем экспресс-сервере с помощью куки-парсера,
и как мы можем настроить подписанные куки.
Это хорошее время для вас сделать git фиксацию с файлами cookie сообщений.