Теперь, когда мы поняли аутентификацию на основе токенов с использованием JSON Web Tokens,
а также поняли преимущества использования этого подхода.
Тот факт, что мы сейчас создаем сервер на основе Rest API,
в этом курсе означает, что
аутентификация на основе JSON Web Token
наиболее подходит для этого сервера, который мы создаем.
Итак, давайте обновим наш сервер API Rest, чтобы использовать JSON Web Tokens в этом упражнении.
Чтобы начать обновление сервера на вашем терминале,
давайте сначала установим JSON Web Token и модуль паспорта JWT Node.
Итак, в подсказке введите npm, установите,
паспорт JWT JSON Web Token и минус сохранить.
Как вы можете видеть, я использую JSON Web Token 8.3.0 и паспорт JWT 4.0.0 в этом курсе.
Теперь, когда мы завершили установку, давайте перейдем и обновим наш экспресс-сервер.
Перейдя сейчас к нашему коду,
давайте добавим в файл
с именем conflict.js в корневую папку нашего проекта.
Теперь этот файл conflict.js я собираюсь использовать его
для хранения некоторой информации о конфигурации для нашего сервера.
Теперь это способ централизации всей конфигурации для нашего сервера.
В этом файле conflict.js
позвольте мне экспортировать объект JSON здесь.
Итак, мы скажем, SecretKey,
и здесь
я укажу секретный ключ, который я собираюсь использовать для подписания моего JSON Web Token,
а также позвольте мне указать URL-адрес Mongo здесь,
который будет URL-адресом для
моего сервера MongoDB localhost 27017.
После того, как мы завершили это,
мы перейдем к файлу authenticate.js,
а в файле authenticate.js мы
теперь создадим стратегию JWT.
Это стратегия веб-токенов JSON, которая предоставляется
нашим паспортным модулем узла JWT, который мы только что включили, и поэтому мы скажем,
стратегия генеративности паспорта generativity.strategy.
Это предоставит нам
стратегию на основе JSON Web Token для настройки нашего модуля паспорта,
а затем извлеките JWT, который я
также получу из паспорта JWT.
Нам потребуется паспорт JWT,
затем мы скажем «Извлечь JWT».
Затем давайте импортируем
модуль JSON Web Token
, который мы только что установили.
После того, как мы импортировали их,
давайте продолжим и начнем настраивать несколько вещей.
Наряду с этим позвольте мне импортировать конфигурацию, которую я
создал файл config.js, который я только что добавил в свой проект.
Как только я закончу это, позвольте мне пойти вперед и
ввести несколько дополнительных функций, которые я буду экспортировать отсюда.
Скажем, Exports.getToken,
эта функция при поставке с параметром, который я просто вызову пользователя,
который будет объектом JSON,
это создаст токен и даст его нам.
Чтобы создать токен, мы будем использовать модуль jsonwebtoken, который мы только что импортировали.
Итак, здесь мы скажем, что return jwt.sign,
это помогает нам создать JSON Web Token и так внутри, что он
позволит мне поставлять полезную нагрузку, а
полезная нагрузка здесь входит как параметр здесь называется пользователем,
а затем второй параметр - это
секретный или закрытый ключ, который я получаю из конфигурации. секретный ключ,
который я только что настроил немного раньше.
Здесь мы можем предоставить дополнительные варианты.
Один из вариантов, который я поставлю на это...
Хорошо, позвольте мне перейти к следующей строке здесь,
вариант, который я поставлю - ExpiResin.
ExpiResin скажет вам, как долго jsonwebtoken будет
действительным, поэтому в этом случае я говорю 3,600, что означает 3,600 секунд или около часа.
Через час вам придется обновить jsonwebtoken.
Часа достаточно для того, чтобы мы могли протестировать наше приложение.
Вы можете установить это намного дольше, если вы решите.
В реальном приложении вы можете установить это гораздо более длительное значение, возможно,
несколько дней, и ожидать, что пользователь будет повторно аутентифицировать себя каждые несколько дней.
Теперь мы также будем настраивать
стратегию на основе jsonwebtoken для нашего заявления на паспорт.
Итак, позвольте мне объявить переменную, называемую opts, что
является не чем иным, как параметрами, которые я собираюсь указать для моей стратегии на основе JWT.
Таким образом, мы скажем, что выбирает JWTFromRequest.
Теперь эта опция определяет,
как jsonwebtoken должен быть извлечен из входящего сообщения запроса.
Здесь мы будем использовать экстракт JWT.
Этот экстракт JWT поддерживает различные методы
для извлечения информации из заголовка.
Он скажет из AuthHeader из AuthHeader в качестве токена носителя,
из заголовка, какая схема и так далее.
Если вы прочитаете документацию, он расскажет
вам различные способы извлечения jsonwebtoken.
Вы можете передать токен в теле
входящего сообщения запроса, а затем вы можете извлечь его оттуда,
вы также можете использовать пользовательские экстракторы и так далее.
В этом курсе я собираюсь использовать самый простой метод, вызываемый
из заголовка аутентификации в качестве токена носителя.
Мы уже знакомы с
заголовком аутентификации, потому что, как мы использовали это с
обычной аутентификацией и аутентификацией на основе файлов cookie ранее.
Итак, я просто собираюсь использовать
это же поле заголовка в сообщении запроса, чтобы нести jsonwebtoken.
Поэтому я скажу, что выбор в качестве маркера jsonwebtoken носителя.
Следующий, мы скажем opts.SecretorKey,
это второй параметр, который помогает мне
предоставить секретный ключ, который я собираюсь использовать в своей стратегии для входа.
Так что это другой вариант, который я собираюсь указать здесь.
Как только я указываю эти два,
позвольте мне экспортировать стратегию Passport,
которую я собираюсь настроить здесь, поэтому мы скажем ExportJwtPassport,
тогда мы скажем passport.use.
Вспомните, как вы указывали локальную стратегию ранее.
Здесь мы указываем стратегию на основе JWT,
тогда мы создадим новую стратегию JWT,
напомним, что мы только что импортировали стратегию JWT
здесь, что мы будем использовать для создания новой стратегии.
Эта стратегия JWT принимает
объект options, который я только что создал в качестве первого параметра.
Варианты стратегии и второй - это функция проверки, которую мне нужно поставить,
и поэтому функция проверки я собираюсь предоставить ее в следующей строке здесь,
мы скажем functionJWT_Payload.
Сделано. Таким образом, когда эта функция
вызывается, выполняется обратный вызов, который предоставляется паспортом.
Таким образом, всякий раз, когда у вас есть паспорт, который
вы настраиваете с помощью новой стратегии, вам нужно указать второй параметр.
С помощью этого параметра
вы будете передавать обратно информацию в паспорт, который он затем будет
использовать для загрузки вещей в сообщение запроса.
Таким образом, когда паспорт анализирует сообщение запроса,
он будет использовать стратегию, а затем извлекать информацию,
а затем загрузить ее в наше сообщение запроса.
Итак, так как это случается, что это функция,
я просто собираюсь использовать функцию стрелки здесь,
я увлекался функциями стрелок.
Итак, позвольте мне создать это как функцию стрелки здесь,
и внутри этой функции,
мы будем определять функцию.
Итак, что мы делаем внутри функции?
Позвольте мне сделать console.log
полезной нагрузки JWT, а затем
позвольте мне просто выйти из опции, входящей сюда,
опция полезной нагрузки JWT здесь,
чтобы вы могли увидеть, что находится внутри полезной нагрузки JWT.
Затем мы будем искать пользователя, сказав user.findone,
а затем я знаю, что в jwt.payload
есть поле ID, которое входит.
Итак, это то, что я собираюсь назначить в качестве поля ID здесь.
Итак, я скажу, user.findone и второй
- это функция обратного вызова.
Как вы понимаете, этот метод пользователя Mongoose, и вы пытаетесь найти.
Итак, мы скажем, если ошибка, то возвращение сделано.
Что это сделало? Это сделано - обратный вызов, который
паспорт будет передавать в вашу стратегию здесь.
Итак, мы будем вызывать эту выполненную функцию.
Это делается в паспорте, принимает три параметра.
Таким образом, вы можете увидеть три части информации, которую это сделано ожидает, что он говорит, ошибка: любой.
Итак, если у вас есть ошибка, вы передадите ее в качестве первого параметра.
Второй параметр, пользователь? ,
Если пользователь существует,
то значение пользователя будет передано, а затем, если какая-либо информация? :, любой.
Таким образом, эти два являются необязательными параметрами и поэтому,
если вы передаете какую-либо информацию,
то это будет использоваться в приложении.
Если я передаю false в качестве второго параметра,
это означает, что пользователь не существует или что.
Таким образом, он будет интерпретировать, что пользователь не существует.
Итак, я мог бы сказать, err,
false, потому что это ошибка.
Итак, я не собираюсь передавать пользовательское значение там,
я просто собираюсь передать в false.
Там, следующий,
мы можем сказать, иначе if (пользователь).
Итак, если пользователь не равен нулю,
мы скажем, return done (null).
Ошибки нет, поэтому первый параметр будет
нулевым, а второй параметр - это пользователь,
но мы только что получили из MongoDB.
В противном случае мы вернемся
с null, false.
Итак, в последнем случае,
мы не смогли найти пользователя,
поэтому мы будем передавать false.
Итак, мы будем справляться с этим вот так.
Если вы хотите, вы можете создать новую учетную запись пользователя на этом этапе,
но я собираюсь сохранить это просто так, чтобы это было легко для нас понять.
Итак, мы просто скажем, нулевое, ложное. Это шесть.
Итак, это стратегия паспорта JsonWebToken, которую я только что настроил здесь.
Кроме того, позвольте мне экспортировать
еще одну функцию отсюда под названием VerifyUser.
Теперь, эта функция VerifyUser,
я собираюсь использовать ее для проверки входящего пользователя.
Итак, здесь я буду использовать passport.authenticate.
Итак, pasport.authenticate, стратегия - это стратегия jwt, которую я только что настроил,
стратегия JsonWebToken, которую я только что настроил.
Затем вторая часть,
я бы сказал, сессия: ложь.
Таким образом, это означает, что
мы не собираемся создавать сессии в этом случае.
Как вы помните, обратное приложение,
мы используем проверку подлинности на основе токенов.
Так что мы не собираемся создавать сеансы.
Поэтому я установил этот сеанс опций на false здесь,
и, конечно же, первый указал стратегию, которую я собираюсь использовать.
Таким образом, для проверки пользователя
я буду использовать стратегию JWT.
Как работает стратегия JWT?
Во входящем
запросе токен будет включен в заголовок аутентификации, как мы видели здесь.
Мы сказали, что заголовок аутентификации как токен носителя.
Если это включено, то это будет извлечено и будет
использоваться для аутентификации пользователя на основе токена.
Незначительное исправление здесь, это должно быть user.Findone_ID равно jwt_payload. _id,
потому что это значение id, которое находится внутри полезной нагрузки моего JsonWebToken.
Итак, мы ищем пользователя с этим заданным идентификатором.
Итак, как только мы закончили это, то теперь,
вторая часть, которую нам нужно сделать, это то, что нам нужно где-то создать токен.
Теперь, где мы создаем токен?
Таким образом, это то, что мы делаем в файле users.js, очень полезно для нас.
В файле users.js
напомните, что у вас уже есть эта конечная точка под названием login.
В конечной точке входа
вы использовали имя пользователя и пароль для аутентификации пользователя.
Таким образом, даже с JsonWebToken для выпуска JsonWebToken,
вам сначала нужно аутентифицировать пользователя, используя одну из других стратегий,
и если вы собираетесь использовать локальную стратегию сначала,
мы проведем аутентификацию пользователя, используя имя пользователя и пароль.
После того, как пользователь
будет аутентифицирован с именем пользователя и паролем, мы выдадим токен пользователю, говорящему:
«Хорошо, вы действительный пользователь,
я собираюсь дать вам токен».
Все последующие запросы будут просто нести токен
в заголовке входящего сообщения запроса.
Итак, раньше мы создавали сеансы.
Когда пользователь аутентифицирован,
мы больше не будем использовать сеансы.
Вместо этого, когда пользователь аутентифицируется с помощью локальной стратегии,
мы выдадим токен пользователю.
Итак, внутри этого метода router.post, который мы сделали на этой конечной точке /login,
я собираюсь создать токен и передать этот токен обратно пользователю.
Итак, здесь мы скажем router.post.
Позвольте мне создать токен.
Чтобы создать токен,
у нас есть эта функция в модуле аутентификации под названием Authenticate.getToken.
Итак, напомним, что у нас уже есть,
чтобы воспользоваться этим, конечно,
еще до того, как мы начнем там,
мне нужно импортировать аутентификацию.
Модуль здесь. Итак, мы скажем, требуется аутентификация. /аутентифицировать.
Итак, тогда, когда в вашем коде здесь,
мы можем сказать Authenticate.getToken,
и getToken принимает параметр здесь.
Теперь, вспомните, возвращаясь к файлу authenticate.js.
Файл authenticate.js принимает один параметр здесь
, который будет использоваться в качестве полезной нагрузки при создании JsonWebToken.
Итак, в файле users.js
я собираюсь создать токен, предоставив полезную нагрузку,
которая содержит только идентификатор пользователя.
Итак, мы скажем id: req.user. _id.
Этого достаточно для создания JsonWebToken.
Мы не хотим включать какую-либо другую информацию пользователя.
Если вы решите, вы можете включить другие части информации о пользователе,
но я бы предложил сохранить JsonWebToken маленьким.
Идентификатор пользователя достаточно, потому что если вам нужно искать пользователя,
идентификатора пользователя достаточно для поиска в MongoDB для пользователя.
Итак, я просто собираюсь кодировать только идентификатор пользователя здесь.
Теперь вы знаете, что req.user уже будет присутствовать,
потому что, когда pasport.authenticate («локальный») успешно аутентифицирует пользователя,
это загрузит свойство пользователя в сообщение запроса.
Вот почему я могу сделать это здесь.
Итак, это то, что я буду использовать для создания токена.
Теперь, как только токен создан,
я хочу передать этот токен обратно пользователю.
Итак, в объекте rest.json, который я поставляю здесь,
я уже ношу флаг успеха, а также
сообщение о статусе здесь.
Позвольте мне добавить токен в
качестве одного из свойств в ответном сообщении здесь.
Итак, токен, который я только что создал,
я передам это обратно как второе свойство внутри этой строки Json здесь.
Итак, теперь, когда мой клиент получает эту строку Json в теле ответного сообщения,
он может войти и извлечь токен оттуда.
Вот оно. Итак, мы обновили файл users.js,
и теперь вы можете увидеть, как маркер будет
создан и отправлен обратно пользователю, когда пользователь успешно аутентифицирован.
Теперь эта схема также может быть использована
при использовании сторонней аутентификации, как на основе OAuth 2.0,
который мы рассмотрим в следующем модуле.
Теперь процедура будет аналогичной.
Вы будете создавать токен, когда пользователь
будет аутентифицирован сторонним поставщиком аутентификации или OAuth, а затем вы передадите токен обратно пользователю,
в аналогичном подходе, как вы видите здесь.
Теперь, как только мы это сделали,
мы переходим к файлу app.js.
В файле app.js, потому что мы включили конфигурационный файл здесь.
Итак, позвольте мне запросить файл конфигурации здесь,
а затем URL-адрес, который я использую здесь, вместо жесткого кодирования этого URL-адреса,
я скажу config.Mongourl.
Итак, теперь вы видите, как мой файл config.js может быть использован
в качестве централизованного места, где я могу подготовить конфигурацию для моего приложения.
Вот оно. Итак, теперь происходит то, что когда пользователь
аутентифицируется на конечной точке /login и пользователь успешно аутентифицирован,
токен будет создан сервером и отправлен обратно клиенту или пользователю.
Таким образом, клиент будет включать токен в
каждый последующий входящий запрос в заголовок авторизации.
Теперь, как он включает заголовок авторизации?
Давайте вернемся к authentic.js и здесь,
вы видите, что мы сказали ExtractJWT.FromAuthHeaderasBearerToken здесь.
Таким образом, это будет включено в заголовок аутентификации в качестве токена носителя.
Я покажу вам, как это делается,
а затем мы используем почтальона, чтобы включить токен носителя в заголовок аутентификации.
Теперь, когда это приходит,
вы помните, что прямо ниже здесь,
вы настроили этот метод здесь под названием VerifyUser,
который вызывает аутентификацию паспорта с помощью JWT.
Таким образом, этот использует токен, который
входит в заголовок аутентификации, а затем проверяет пользователя.
Таким образом, в любое время, когда я хочу проверить подлинность пользователя,
я могу просто вызвать пользователя verify,
и это инициирует вызов passport.authenticate и проверяет sser.
Если это будет успешным,
это позволит мне продолжить работу.
Эта процедура очень похожа на то, что вы сделали в
файле users.js, где вы вызываете тот же паспорт.authenticate («локальный»).
Итак, если это успешно,
то вы идете вперед.
В случае сбоя функция аутентификации вернет
клиенту сообщение об ошибке, в котором говорится, что пользователь не авторизован.
Итак, об этом уже позаботились.
Итак, теперь, когда мы включили это в мой файл authenticate.js,
любое место, в котором я хочу проверить пользователя,
я могу просто вызвать
эту функцию VerifyUser, которую
я указал здесь, или экспорт, который я указал здесь,
который мы будем вызывать passport.authenticate с помощью
стратегия JWT для аутентификации пользователя.
Итак, как нам это использовать?
Теперь мы собираемся пойти в каждый из наших маршрутизаторов
и контролировать опции на всех маршрутах, которые мы хотим контролировать.
Итак, возвращаясь к файлу app.js, теперь
, когда мы не используем сеансы, я собираюсь удалить этот сеанс отсюда,
потому что мы больше не используем сеансы.
Аналогичным образом, я также собираюсь удалить этот паспорт.session отсюда.
В этом тоже нет необходимости.
Кроме того, эта проверка подлинности, см. ранее,
когда я настраивал эту проверку подлинности,
эта проверка подлинности применялась к каждому входящему запросу.
Теперь я собираюсь изменить свое приложение, в
результате чего я буду требовать аутентификации только на определенных маршрутах, а не на всех маршрутах.
Итак, позвольте мне полностью удалить эту аутентификацию из app.js.
Итак, теперь, когда запрос приходит,
если он включен/конечная точка,
индекс будет обслуживаться.
Если он находится на конечной точке /users, он позволит вам перейти к
различным маршрутам, которые смонтированы на /users в users.js
, а затем к остальным маршрутам.
То, что я собираюсь сделать сейчас, это оставить
общедоступную папку открытой для всех, чтобы получить доступ.
Теперь, во многих приложениях,
это может быть просто отлично.
Так что, я оставлю это открытым.
Теперь, на блюдах
, акциях и конечной точке лидеров,
все запросы получить.
Я позволю ответить на них, не требуя никакой аутентификации.
Зачем мне это делать?
Если пользователь выполняет запрос на получение,
пользователь просто хочет получить информацию.
Итак, например, на стороне клиента, если я реализую веб-приложение с помощью Angular
или клиентское приложение с использованием Ionic или собственного сценария,
тогда, возможно, я хочу реализовать свое приложение
таким образом, чтобы на главной странице уже
отображалась информация, генетическая информация, которую вы хотите сделать доступным для всех, кто
посещает ваш веб-сайт или открывает ваше приложение.
Таким образом, там можно отобразить основную информацию.
Но если вы хотите что-то изменить,
вы ожидаете, что пользователь будет аутентифицирован.
Таким образом, вы разрешаете операции POST,
операции ввода и удаления выполняться только аутентифицированными пользователями.
Аналогично, например, для комментариев
можно сказать, что комментарии могут быть размещены или изменены только аутентифицированными пользователями.
Таким образом, вы можете ограничить только некоторые маршруты для аутентифицированных пользователей,
другой маршрут вы можете оставить их открытыми. Как нам это сделать?
Теперь это то, где пользователю проверить, что мы
экспортировали из файла authenticate.js, пригодится.
Теперь вместо того, чтобы контролировать все конечные точки,
все различные операции по тарелкам, акциям
и лидерам в точках,
мы будем открывать только операции get для кого угодно,
но
операции post, put и delete будут ограничены только аутентифицированными пользователями.
В назначении вы добавите еще в одну категорию пользователей, называемых администраторами.
Теперь вы ограничите определенные операции, которые будут выполняться только администраторами.
Так, например, изменение блюд
или удаление информации о блюдах из базы данных,
будет ограничено только администраторами.
Но основные пользователи могут размещать комментарии,
изменять комментарии, которые они опубликовали,
и, возможно, даже сохранять некоторые любимые блюда.
Мы сделаем эту часть в четвертом модуле.
Итак, как мы контролируем конкретные маршруты?
Таким образом, это место, где мы должны войти в каждый из маршрутизаторов,
а затем импортировать элементы управления на определенных маршрутах.
Итак, давайте начнем с маршрута блюд.
Итак, для маршрута блюд,
вы вспомните, что это контролируется в файле dishRouter.js.
Итак, перейдя к dishRouter.js,
давайте сначала импортируем аутентификацию здесь.
Итак, скажем, const authenticate
требует../authenticate, потому что этот
файл authenticator.js находится в папке более высокого уровня.
Итак, помните../аутентифицируйте здесь.
Итак, как только вы импортируете аутентификацию,
для маршрута маршрутизатора тарелки для этого маршрута
, операция get, я собираюсь разрешить без каких-либо проблем.
Итак, это открыто.
Так что я не собираюсь накладывать никаких ограничений.
Из сообщения, если мы хотим применить несколько промежуточного программного обеспечения,
мы можем просто добавить основной внутри этого позади другого.
Теперь, когда вызывается сообщение,
прямо сейчас вы просто выполняете эту функцию здесь.
Теперь как раз перед этим
я могу войти и сказать, Authenticate.verifyUser, там.
Итак, что это делает?
Это говорит, что если поступит запрос на пост,
я сначала выполню это промежуточное программное обеспечение,
которое я экспортировал из файла authentic.js,
я сначала применяю
это, что эквивалентно тому, что паспорт аутентифицирует JWT, и вы проверяете пользователя.
Тогда, если это
будет успешно, то я перейду, чтобы сделать остальное.
Если проверка подлинности завершается неудачей на данном этапе,
проверка подлинности паспорта будет отвечать
клиенту с соответствующим сообщением об ошибке.
Таким образом, это уже обрабатывается паспортной аутентификацией,
поэтому мне не нужно беспокоиться ничего за пределами этого момента.
Если я пересек это промежуточное программное обеспечение, а затем
выполнил следующую функцию, что означает, что моя аутентификация была успешной,
поэтому я могу продолжить с этого момента.
Таким образом, это действует в качестве барьера для этого метода поста.
Теперь, используя тот же аргумент,
я могу просто применить это конкретное промежуточное программное обеспечение ко всем другим методам.
Я могу это сделать.
Хотя в этом случае,
положить не собирается ничего делать.
Но в любом случае,
я просто просто ради
единообразия, я буду применять пользователя проверки, чтобы также поставить и, конечно же,
для удаления тоже, я собираюсь применить put.
Аналогичным образом, спустившись к /dishid,
я позволю этому работать без каких-либо проблем.
Post, я применим пользователя проверки.
Поместите также я применим пользователя проверки и для удаления также то же самое.
Для /dishid/comments я собираюсь оставить get open,
это нормально для любого, чтобы получить комментарии о конкретном блюде.
Post, я собираюсь закрыть это,
поэтому только проверенные пользователи могут публиковать комментарии.
Поставьте также я закрою это и удалю тоже.
Вам нужно сделать еще один шаг и сказать:
«Только пользователи, которые разместили комментарий, могут удалять свои собственные сообщения».
Но мы сделаем это в следующем модуле.
На данный момент я скажу:
«Хорошо, проверенный пользователь может удалить любой комментарий».
Это, конечно, не так,
мы можем поставить дополнительные проверки,
но мы сделаем это в следующем модуле этого курса.
Итак, для удаления также я применяю то же самое.
Опять же, для комментариев маршрутизатора тарелки/комментариев Id,
я оставлю его открытым.
Пост, я оставлю его закрытым.
Поставьте также закрыть его, а затем для удаления, также я закрою это.
Удалить, конечно, как я сказал,
операция удаления должна быть разрешена только пользователю, который
создал комментарий, следует попросить удалить его,
но вам нужно настроить несколько дополнительных вещей, чтобы это работало правильно,
что мы сделаем в следующем модуле.
На данный момент мы говорим, что проверенный пользователь может удалить конкретный комментарий, вот и все.
Теперь мы применим тот же принцип к промо-роутеру, а также к лидеру роутера.
Итак, зайдя в промо-роутер,
позвольте мне импортировать аутентификацию,
а затем получить открыт,
так что это лидер маршрутизатор.
Так что, добраться открыт.
Сообщение, я собираюсь контролировать, что,
поставить, контролировать, удалить, контролировать,
лидер маршрутизатор, лидер ID,
получить хорошо, пост,
контролируется, поставить контролируется и удалить контролируется.
То же самое с промо-роутером.
Позвольте мне, потребовать аутентификации,
а затем для получения маршрута открыт,
POST контролируется, поставляется контролируется,
удаление контролируется, то же самое для Promorouter/PromoID.
Get открыт, POST контролируется,
put и delete также контролируются, вот и все.
Давайте сохраним все изменения.
Итак, как только мы завершим все изменения,
давайте сохраним изменения.
Теперь наше приложение готово к тестированию.
Итак, давайте перезапустим наш сервер,
или если сервер не работает,
мы просто запустим сервер.
Переходя к терминалу,
мой сервер не работает.
Итак, позвольте мне запустить сервер, набрав npm start.
Интересно, что он просто вызвал ошибку здесь,
я просто хотел проиллюстрировать вам, что даже я могу ошибаться,
поэтому вы увидите, что здесь есть ошибка, которая говорит:
«Не удается найти module.authenticate», а затем, если я просмотрю код,
я обнаружу, что эта проблема возникла в
где это произошло?
Итак, я просто ищу здесь,
а затем где-то здесь,
я заметил, что эта проблема возникла внутри моего файла users.js.
Итак, прямо там, говорится,
это в файле users.js.
Итак, перейдя к файлу users.js, давайте исправим это.
Перейдя к файлу users.js,
прямо в верхней части, когда мне требуется аутентификация, я сказал:
«.authenticate», и, как я говорил вам, это
должна быть точка, потому что она находится в верхней папке.
Этот файл users.js в папке Routes
и аутентифицировать находится в папке Projects Route, поэтому это должно быть точкой аутентификации.
Итак, если вы совершаете ошибки, вы идете туда,
вот как вам напомнят об ошибке, которую вы ввели.
Итак, давайте сохраним изменения, а затем перезапустите наш сервер.
Опять же, возвращаясь к этому терминалу,
позвольте мне запустить мой сервер, и мой сервер теперь работает,
давайте перейдем к Почтальону, а затем протестируем наше приложение.
Теперь, в Postman, позвольте мне сначала попробовать сделать
GET на локальном хосте: 3000/блюда, а затем, когда я делаю GET,
это успешно, потому что конечная точка GET не контролируется.
Таким образом, я могу сделать GET на блюдах,
я могу сделать GET на акциях,
и все это работает отлично.
Но если я попытаюсь сделать POST на блюдах,
так что позвольте мне найти, где я сделал POST на блюдах.
Здесь я сделал POST на блюда.
Поэтому, когда я попытался сделать POST на посуду,
он сразу говорит несанкционированный.
Таким образом, мой модуль Passport понял, что я не уполномочен, поэтому мне не разрешено это делать,
так что это то, о чем он напоминает мне.
Позвольте мне очистить файлы cookie,
в случае, если вы найдете файл cookie в своем Почтальоне, просто удалите файл cookie,
соответствующий localhost
, потому что этот файл больше не нужен и не потребуется.
Таким образом, даже если я удалю файл cookie, а затем POST,
он все равно скажет несанкционированный.
Итак, я не уполномочен делать эти операции.
Итак, я должен войти в систему.
Теперь, если вы выполнили предыдущее упражнение,
вы бы оставили пользователя, зарегистрированного ранее.
Итак, например, вы бы зарегистрировали этого конкретного пользователя в предыдущем упражнении,
позвольте мне попытаться снова зарегистрировать одного и того же пользователя, и
мой сервер должен жаловаться на то, что userExistSerror, так что это означает, что пользователь существует,
поэтому мне не нужно снова регистрироваться.
Если вы удалили пользователя из вашего MongoDB,
просто зарегистрируйте этого пользователя еще раз, а затем давайте войти в систему.
Таким образом, мы отправим запрос на вход в эту конечную точку.
Итак, когда я отправляю запрос на вход, выполняя POST конечному пользователю,
обратите внимание, что возвращается моим сервером.
Вы сразу же заметите, что в
ответном сообщении вместе с флагом успеха и сообщением о состоянии
вы также получите маркер здесь.
Теперь, этот конкретный токен,
мне нужно скопировать этот токен,
потому что в моих последующих запросах
мне нужно будет включить этот токен.
Итак, позвольте мне перейти к сырой версии этого и что я собираюсь скопировать этот токен.
Этот токен - не что иное, как длинная строка,
поэтому позвольте мне скопировать этот токен.
Тогда теперь, если вам интересно, что содержится в этом токене,
JSON Web Token можно изучить.
Существует конкретный сайт, где вы можете войти и ввести
свой веб-токен JSON, а затем фактически проверить, что находится внутри веб-токена JSON.
Давайте сделаем это в качестве следующего шага.
В окне браузера
просто введите jwt.io, и это приведет вас на этот сайт под названием JSON Web Token jwt.io.
Если вы помните, в лекции
я показал вам структуру JSON Web Token
и показал вам, что JSON Web Token содержит три части: заголовок
, полезную нагрузку и информацию там.
Теперь, в этом случае,
информация здесь, поэтому я собираюсь
вставить свой JSON Web Token в эту левую сторону,
поэтому позвольте мне выбрать это, а затем вставить мой JSON Web Token в
левую сторону в закодированной части, а затем на правой стороне,
он показывает вам, что именно внутри веб-токена JSON, который я только что создал.
Итак, он говорит, что заголовок содержит эти две части информации.
Полезная нагрузка замечает, что она содержит идентификатор
пользователя, а затем подпись внизу здесь.
Итак, это то, что содержится в моем JSON Web Token.
Возвращаясь к
почтальону, позволь мне попробовать взять блюда.
Итак, когда я говорю GET localhost: 3000/diss,
он все равно вернет пустую строку,
пустой массив здесь, потому что моя база данных не содержит ее.
Итак, позвольте мне POST блюдо в мою базу данных.
Итак, я собираюсь выбрать операцию POST и в теле,
вы видите, что мое блюдо здесь.
В заголовке я собираюсь добавить новый заголовок под названием
авторизация, и вы помните, что ранее для базовой авторизации
вы сказали basic, а затем у вас была закодированная строка Base 64 там.
Если вы хотите включить свой JSON Web Token в заголовок авторизации,
потому что в нашем коде
мы сказали авторизацию как токен на предъявителя.
Итак, если вы хотите включить токен в заголовок авторизации,
в авторизации мы скажем носитель, а затем мы вставим ту
строку токена, которую мы только что скопировали из нашего входящего запроса.
Итак, мы вставим строку токена туда.
Итак, это то, что будет содержаться в
заголовке авторизации моего исходящего запроса здесь,
исходящий запрос POST здесь.
Итак, обратите внимание, что левая сторона говорит, что носитель, а правая сторона - это строка,
токен, который я только что скопировал с
точки, где я вошел в систему, а затем позвольте мне отправить сообщение POST
сейчас, и мой POST теперь успешно, и это опубликовано в моей базе данных.
Теперь, если вы хотите быть уверены, что он был опубликован,
давайте сделаем GET, и когда вы делаете GET,
вы можете увидеть, что действительно это блюдо было вставлено в мою базу данных, как показано здесь.
Итак, вот как вы будете использовать JSON Web Tokens в вашем приложении.
Таким образом, всякий раз, когда вам нужно выполнить
операцию POST, PUT или DELETE на любой из конечных точек,
вы будете заключены.
Итак, позвольте мне вернуться к этому запросу POST здесь.
В заголовке вы поместите
это поле авторизации, а затем это будет включено в авторизацию,
вы начнете его с носителя, а затем строку маркера,
после этого пространства носителя,
одно единственное пространство, а затем строка маркера, следующая за этим.
Таким образом, ваши сообщения запроса будут
нести JSON Web Token в заголовке исходящего сообщения запроса.
Вы также можете включить токен в тело исходящего сообщения запроса.
Теперь для этого вам придется настроить
свой экспресс-сервер, особенно дополнительный JWT в
файле authenticate.js, чтобы принять его из
тела, чтобы вы помните, что там мы видели, что
дополнительный JWT поддерживает множество различных способов извлечения
JSON Web Token из входящего запрос.
Итак, там нужно указать,
если вы собираетесь включить его в тело,
вам нужно указать эту информацию там.
Теперь подробно о том, как это сделать, вы можете проконсультироваться с
документацией модуля Passport JWT, чтобы понять, как это делается.
В этом курсе я просто использую это в заголовке авторизации,
как я показал здесь, и это отлично работает в большинстве случаев.
Теперь, если вы разрабатываете веб-приложение,
угловое приложение или приложение Ionic или NativeScript,
вам нужно иметь возможность настроить
это приложение, в котором JSON Web Token будет включен в заголовок авторизации.
В последнем уроке этого курса
я покажу вам, как интегрировать клиента и сервера,
клиента, который вы разработали в предыдущих курсах, с
сервером, который мы разработали в этом курсе.
С этим мы завершаем это упражнение.
В этом упражнении мы видели, как мы
можем настроить наше приложение для использования JSON Web Token,
и мы видели, как мы обрабатываем аутентификацию пользователя с помощью JSON Web Token,
используя поддержку из модуля Passport и модуля Passport JWT,
а также модули JSON Web Token Node.
С этим мы завершаем это упражнение.
Это хорошее время для вас сделать Git Commit с сообщением Passport JWT.