Теперь, когда мы поняли паспорт и как паспорт добавляет
в простое промежуточное программное обеспечение аутентификации для нашего приложения NodeJS,
и обеспечивает гибкий простой в настройке
способ и предоставляет различные стратегии для аутентификации пользователей,
давайте отправимся в путешествие с нашим паспортом.
Для начала этого упражнения,
в качестве первого шага, давайте установим
модули паспорта, локального паспорта и паспорта-локального монгуста в наш сервер путаницы.
Таким образом, в командной строке введите npm instal_passport,
passport-local, паспорт local-mnoose mnus минус сохранить и установить эти три модуля.
Как вы можете видеть на данный момент мы начинаем с
версии паспорта 0.4.0, паспорта-локального 1.0.0 и паспорта-локально-мангуста 5.0.1 в этом курсе.
Теперь, когда мы установили паспорт, паспорт-локальный и паспорт-локаль-мангуст,
давайте перейдем к серверу путаницы и перейдем к файлу user.js.
Мы обновим пользовательскую схему и модель, чтобы использовать паспорт-локаль-мангуст.
Для этого здесь мы скажем, что
var passportLocalMongoose
требует паспорта-локального мангуста.
Таким образом, это мы установим как
плагин mongoose в нашем приложении, и мы можем удалить имя пользователя и
пароль, потому что они будут автоматически добавлены в
passport-local-mongoose плагин здесь и
использовать это как плагин в нашей схеме и модели мангуста.
Мы скажем, пользователь подключите и паспорт-локальный мангуст.
Таким образом, это будет автоматически, как я сказал, добавляя поддержку
имени пользователя и хэшированного хранения пароля с использованием
хэша и соли и добавляя
дополнительные методы в пользовательскую схему
и модель, которые полезны для аутентификации паспорта.
Поэтому, как только мы завершим обновление файла user.js, а затем в нашей папке проекта,
мы создадим новый файл и назовем его как authenticate.js.
В файле authentic.js
позвольте мне импортировать паспорт.
Таким образом, мы скажем, требуется паспорт, и мы собираемся
использовать этот файл для хранения стратегий аутентификации, которые мы будем настраивать.
Так что мы скажем Вар. LocalStrategy требует
паспорт-локальный, поэтому локальный модуль паспорта экспортирует стратегию, которую мы можем использовать для нашего приложения.
Таким образом, мы скажем Passport-Local.strategy,
а затем мы импортируем пользователя из модели пользователя.
Давайте теперь настроим паспорт с новой локальной стратегией,
а затем мы будем экспортировать это из этого файла, потому что это будет модуль узла.
Итак, мы скажем exports.local и мы скажем паспорт, и вы
можете видеть, что паспорт поддерживает различные методы
здесь, поэтому мы скажем использование паспорта и скажем
новую LocalStrategy, а затем это то, где
функции, которые поддерживаются паспорт-локаль-мангуст приходит к нам на помощь.
Таким образом, локальная стратегия должна быть снабжена функцией проверки.
Внутри этой функции мы проверим пользователя.
Эта функция проверки будет вызвана с именем пользователя и паролем, которые
паспорт извлечет из нашего входящего запроса.
Теперь во входящем запросе для LocalStrategy имя пользователя и пароль
должны быть указаны в теле сообщения в виде строки Json.
Опять же, потому что мы делаем body-парсер, так что будет
добавлен в тело сообщения, а затем оттуда паспорт
мы получим это, а затем используем его и поставим имя пользователя и пароль в
качестве параметров для функции проверки, которую мы поставим в LocalStrategy.
Поскольку мы используем плагин passport mongoose,
сам плагин mongoose добавляет эту функцию под названием user.authenticate.
Таким образом, он добавляет этот метод в пользовательскую схему и модель.
Мы собираемся предоставить это как функцию,
которая будет обеспечивать аутентификацию для LocalStrategy.
Теперь, если вы не используете
pasport-local-mongoose, когда вы настраиваете плагин mongoose,
который мы сделали, если
вы не используете его, вам нужно написать свою собственную функцию аутентификации пользователя здесь.
В лекции ранее
я показал вам простую функцию аутентификации пользователя,
которая может быть использована здесь, но тот, который
поставляется модулем pasport-local-mongoose является более
всеобъемлющим, и это то, что мы будем использовать в нашем приложении.
Кроме того, поскольку мы по-прежнему используем сеансы для отслеживания пользователей в нашем приложении,
нам нужно сериализовать и десериализовать пользователя.
Таким образом, это в основном принимает информацию о пользователе.
Теперь напомним, что аутентификация паспорта будет монтировать req.user или свойство пользователя к
сообщению запроса и таким образом,
чтобы информация о пользователе была сериализована и десериализована с помощью
этого слова сериализовать пользователя и паспорт десериализовать пользователя.
Также мы скажем, что пользователь десериализует пользователя.
Эти две функции они сериализуют пользователя и десериализуют пользователя предоставляются
в пользовательской схеме и модели с помощью плагина passport-local-mongoose здесь.
Таким образом, это позаботится о том, что необходимо для
нашей поддержки сеансов в паспорте.
Таким образом, как только мы завершим это обновление файла authenticate.js,
этот файл потребуется везде, где он необходим для нас, чтобы использовать в нашей аутентификации.
Далее, перейдя к файлу users.js,
в файле users.js,
мы сначала импортируем паспорт.
Так что скажем, вар паспорт требует паспорта.
Затем, поскольку мы используем локальный плагин mongoose,
плагин mongoose сам поставляет некоторые метрики, которые
полезны для нас для использования в процессе регистрации и в процессе входа.
Таким образом, спускаясь к сообщению маршрутизатора здесь,
плагин mongoose предоставляет нам метод, называемый регистр,
в пользовательской схеме и модели.
Таким образом, мы скажем, регистрация пользователя, и это будет превращено в говорящего нового пользователя.
Этот новый пользователь является первым параметром, который принимает регистр,
а вторым параметром является пароль req body.
Таким образом, пароль, который входит в качестве второго параметра в теле сообщения.
Поэтому помните, что имя пользователя и пароль передаются,
когда вы регистрируетесь в теле сообщения.
Теперь, в этом случае,
это приведет к функции обратного вызова, предоставляющей ошибку,
и пользователь в качестве двух значений обратного вызова здесь, и, к сожалению,
это тогда не работает в этом случае.
Поэтому мне придется вырезать это отсюда, а затем
вместо этого обрабатывать это внутри этого метода обратного вызова здесь.
Итак, позвольте мне просто отбросить
это, чтобы было легче увидеть код здесь.
Поэтому я скажу, что регистрация пользователя и первый параметр - это
новый пользователь, созданный с
именем пользователя здесь, а второй параметр - это пароль,
а затем результат - это функция обратного вызова, которая вызовет,
мы скажем, ошибка пользователя здесь.
В этом случае мы должны немного отредактировать код здесь.
Итак, в первой части
мы скажем, если ошибка,
то им придется явно отправить ответ.
Итак, я просто скопирую эти два здесь.
Таким образом, мы скажем, если ошибка,
то код статуса res,
мы установим это на 500 и установим тип содержимого заголовка, а затем,
мы установим res json, а затем ошибку, ошибку.
Таким образом, мы построим объект json с ошибкой
в качестве значения свойства error там, а затем отправим это обратно.
Так вот, как вы будете обрабатывать ошибку в этом случае.
В противном случае, то, что мы делаем здесь, это то, что мы
скажем, паспорт аутентифицировать местный.
Поэтому, если мы собираемся использовать паспорт для проверки подлинности пользователя снова.
Так что скажем, паспорт аутентифицирует местный.
Чтобы убедиться, что регистрация пользователя прошла успешно.
мы попытаемся аутентифицировать того же пользователя, что мы только что зарегистрировали, и
здесь мы скажем req res, и это
вернет в качестве третьего значения, что функция внутри которой,
мы собираемся отправить ответ нашему клиенту.
Так что скажем. Позвольте мне удалить это, а затем добавить его сюда.
Теперь мы можем удалить это тогда,
потому что это тогда не является необходимым для нас, и это закрытие регистра пользователя.
В другой части,
мы будем делать паспорт аутентифицировать местный.
Посмотрите на синтаксис здесь.
Таким образом, это паспорт аутентифицировать локальный, а затем после этого,
мы должны вызвать эту функцию здесь, что параметры req,
res и что третий является функцией обратного вызова здесь.
Таким образом, это так реализуется, потому что паспорт ожидает, что вы сделаете это таким образом.
Здесь мы установим код статуса req res 200,
установите заголовок содержимого приложения json, а затем мы будем
res json регистрации статуса успешно, и мы не будем передавать значение пользователя здесь.
Вместо этого, то, что я сделаю, я
установлю флаг, называемый успехом здесь.
Теперь таким образом, на нашей стороне клиента, когда этот json получен,
клиент может просто извлечь свойство успеха, а затем проверить, верно ли это
или нет, чтобы быстро проверить, была ли регистрация успешной или нет.
Так вот, как мы будем обрабатывать процесс регистрации пользователей здесь.
Так что обратите внимание, как код значительно упростился.
Если пользователь не зарегистрировался должным образом,
то это отправит обратно сообщение об ошибке, а также проверка подлинности завершится неудачей.
Таким образом, в обоих случаях вы поймете ситуацию, когда аутентификация пользователя не выполняется.
Теперь сам процесс входа также значительно упрощается.
Таким образом, нам не нужно делать все это в маршруте входа здесь.
Поэтому я собираюсь удалить весь этот код, и этот маршрут входа упрощается здесь.
Теперь для логина путь - для сообщения маршрутизатора, когда мы делаем это здесь,
здесь также мы ожидаем, что имя пользователя и пароль будут включены
в тело сообщения, которое приходит к ней.
В отличие от предыдущего случая, когда мы включали это в заголовок авторизации,
здесь мы ожидаем, что это будет включено в тело входящего сообщения.
Таким образом, чтобы проверить подлинность, мы просто скажем паспорт аутентифицировать, и мы скажем здесь местный.
Так что это будет второй звонок здесь.
Так что это второе промежуточное программное обеспечение, которое мы собираемся сократить.
Поэтому, когда сообщение маршрутизатора приходит на конечной точке входа,
мы сначала вызовем паспорт аутентифицировать локальный.
Если это успешно, то это придет
и следующая функция будет выполнена.
При возникновении какой-либо ошибки при проверке подлинности
этот локальный паспорт автоматически
отсылает клиенту ответ об ошибке проверки подлинности.
Так что об этом уже позаботились.
Поэтому обратите внимание, как код в процессе входа значительно упрощается.
Итак, если это пройдет успешно,
мне нужно только проверить req и res, и здесь, что я буду делать,
я просто отправлю сообщение на клиентскую сторону с этой информацией здесь.
Мы скажем, код состояния res 200,
res установить тип содержимого заголовка приложения json и res json успех true статус.
Скажем, вы успешно вошли в систему.
Вот оно. Это изменение, которое мы собираемся внести в файл users.js.
Так что обратите внимание, как благодаря паспорту пользователя,
как процессу регистрации, так и процессу входа в систему,
код значительно упростился в этом случае.
Теперь мы перейдем к обновлению файла app.js на app.js сейчас.
В app.js прямо здесь
мы введем паспорт.
Затем мы импортируем
модуль аутентификации, который мы только что реализовали.
Мы скажем, var authenticate и в файле app.js ниже здесь после сеанса
мы добавим app.use (pasport.initialize)
и app.use (.session).
Если пользователь вошел в систему,
то происходит то, что когда сеанс инициируется снова,
вы помните, что при входе здесь
вы будете входить здесь,
и вызов паспорта аутентифицировать локальный,
когда это делается на этапе входа в систему,
паспорт аутентифицировать локальный будет
автоматически добавляют свойство пользователя в сообщение запроса.
Таким образом, он добавит req.user, а затем
сеанс паспорта, который мы сделали здесь, автоматически
сериализует эту информацию пользователя, а затем сохранит ее в сеансе.
Итак, и впоследствии, всякий раз, когда
входящий запрос поступает
со стороны клиента с уже установленным файлом cookie сеанса,
это автоматически загрузит req.user во входящий запрос.
Итак, именно так организована сама паспортная сессия.
Таким образом, как только это будет сделано,
даже наш код аутентификации станет намного проще здесь.
Итак, в коде аутентификации
мы просто скажем, если req.user.
Таким образом, req.user будет загружен промежуточным программным обеспечением сеанса паспорта автоматически,
и поэтому мы скажем req.user.
Если не req.user мы скажем var err, новая ошибка,
вы не аутентифицированы, и все эти сообщения здесь.
В противном случае, см. часть else также теперь упрощается.
Скажем еще дальше.
Таким образом, ваш код аутентификации становится намного проще, потому что если req.user отсутствует,
то это означает, что аутентификация не была выполнена правильно,
поэтому вы указываете ошибку.
В противном случае вы прошли проверку подлинности.
Если req.user присутствует, это
означает, что паспорт выполнил аутентификацию, и
пользователь req.user загружается в сообщение запроса,
и поэтому вы можете просто пойти дальше вниз.
Итак, это изменение, которое нам нужно сделать в app.js.
Давайте сохраним все изменения, а затем посмотрим на приложение в Postman.
После сохранения всех изменений перезапустите сервер.
Если сервер запущен,
остановите его и перезапустите сервер.
Позвольте мне запустить сервер.
Как только сервер будет запущен и запущен,
давайте отправимся в Почтальон и сделаем несколько запросов.
Отправляясь в Почтальон, позвольте мне теперь попытаться зарегистрировать нового пользователя,
сделав сообщение о том, что пользователи регистрируют конечную точку.
Когда регистрация размещена,
вы увидите, что в тексте ответного сообщения говорится: «
Успех true» и регистрация статуса успешно.
Таким образом, пользователь успешно зарегистрирован на стороне клиента.
Итак, теперь позвольте мне сделать логин пользователя.
Итак, мы скажем: «Войти», и все равно укажите
имя пользователя и пароль в теле сообщения здесь.
Итак, когда я нажимаю на «Отправить»,
вы сразу заметите, что внизу,
он говорит, успех, правда и статус,
вы вошли в систему, а затем в самом заголовке,
вы увидите set-cookie, который приходит, потому что мы настраиваем сеанс,
а затем вы видите файл cookie на месте.
Когда вы нажимаете на куки,
вы видите идентификатор сеанса прямо там.
Итак, теперь мы успешно вошли в систему.
Давайте отправим запрос в конечную точку Get localhost: 3000 блюд.
Вы видите, что ваш запрос поступил успешно, а затем был отправлен ответ.
Конечно, на данный момент
моя база данных пуста, поэтому она отправляет пустой массив
с сайта сервера, когда я запрашиваю локальный хост: 3000/блюда.
Это прекрасно.
Позвольте мне теперь выйти из системы пользователя.
Итак, когда я выхожу пользователя, теперь
вы заметите, что пользователь вышел из системы, и когда вы нажмете на куки,
вы заметите, что, что куки для localhost уже исчезли.
Итак, теперь, если вы попытаетесь сделать get на localhost: diss,
вы видите, что в ответе говорится, что
вы не аутентифицированы.
Давайте войдем еще раз, сделав сообщение на логине пользователей,
а затем, вы видите, что мы можем успешно войти в этот момент.
Вы также заметили,
что новый файл cookie был настроен здесь.
Затем, если мы сделаем получить на локальном хосте: блюда здесь,
сейчас, это будет успешным.
Поскольку мы используем passport-local mangoose как плагин mongoose,
давайте также пойдем и проверим наш сервер MongoDB, чтобы увидеть, как
информация пользователя фактически хранится в нашем MongoDB.
Итак, в вашем терминале
вы можете открыть пульсацию Mongo,
так что давайте скажем Mongo на терминале, а затем подключимся к нашему серверу MongoDB,
а затем скажем, используйте UniCtract.
Затем мы скажем db.users.find () .pretty (), а затем распечатаем информацию пользователя.
Таким образом, когда вы распечатываете информацию пользователя, как вы видите здесь,
есть один пользователь, который мы зарегистрировали ранее.
Итак, вы увидите, что запись пользователя содержит идентификатор объекта, а затем
имя пользователя ниже здесь, а
флаг администратора, который является ложным, а затем,
также обратите внимание, что вместо хранения самого пароля, что
делает плагин Mongos pasport-local mongoose, он хранит
его значение соли здесь и хэш-значение здесь.
Теперь плагин Mongo делает, так это то, что он будет использовать соль как способ
шифрования пароля и установить хэшированный пароль в этом хэш-поле здесь.
Таким образом, когда вы пытаетесь войти в систему,
он применит то же самое преобразование к входящему паролю,
а затем попытается сопоставить его с этим хэш-значением, которое хранится здесь.
Таким образом, вы можете видеть, что в самой базе данных
пароль не хранится непосредственно внутри
хэшированного значения пароля, который хэшируется с помощью этого ключа соли здесь,
который мы видим здесь,
хранится в записи там.
Таким образом, это как паспортно-локальный плагин Mongoose позволяет
нам хранить информацию о пользователе в нашей базе данных.
Благодаря этому быстрому пониманию того, как паспорт, паспорт-локальный
и паспорт-локальный Mongoose помогают нам упростить
локальную стратегию для имени пользователя и пароля в нашем приложении.
Мы завершаем это упражнение.
Это хорошее время для вас сделать Git фиксацию с паспортом сообщения.