[MUSIC]
Мы уже разработали полноценный API-сервер REST с использованием Express и
MongoDB в рамках этого курса.
Для того, чтобы сервер имел возможность полноценно общаться с нашим клиентом,
мы внесем в него несколько незначительных корректировок, чтобы он возвращал правильные данные.
Чтобы наша клиентская реализация могла более эффективно работать
с данными, возвращаемыми с нашего сервера.
Поэтому, чтобы сделать это,
давайте поработаем над несколькими корректировками на нашей серверной стороне в этом упражнении.
Перейдя на наш сервер в редакторе, прежде чем мы начнем работать на сервере,
я бы предложил вам скачать все изображения, которые я предоставил в
виде zip-файла в ресурсах упражнения под названием images.zip.
Разархивируйте файл, а затем получите все изображения оттуда, а
затем скопируйте эти изображения в общедоступную папку изображений на нашем сервере.
Таким образом, вы видите, что здесь я скопировал все изображения в мою общую
папку изображений здесь уже.
Потому что наш сервер - это тот, который будет обслуживать все эти изображения для
нашего клиентского приложения.
Затем мы перейдем к корсам и подстроим этот белый список.
Поэтому для нашего углового клиентского приложения, если мы запустим его
с помощью команды ng serve, он работает на локальном хосте: 4200.
Таким образом, любые запросы, поступающие из нашего углового
приложения на сервер, будут нести это как их происхождение там.
Вот почему я собираюсь добавить это в свой белый список,
чтобы любые проблемы cors были решены автоматически.
Поэтому, перейдя
в этот файл cors.js, в моем белом списке, позвольте мне добавить
в http://localhost:, 4200.
И это источник, из которого все мои Angular клиент будет
исходить запрос, который приходит на этот сервер.
Таким образом, мои cors не вызовут проблем для клиента Angular.
Далее нужно обновить несколько маршрутов для обработки
параметров запроса, а также несколько незначительных других корректировок.
Позвольте мне начать с файлов promoRouter.js.
Так что это просто обновить.
Поэтому, перейдя в файл promoRouter.js, в файле Promorouter, для
запроса получения, который мы получаем здесь,
вместо того, чтобы делать promotions.Find с пустым JavaScript,
здесь я бы предоставил req.query
в качестве параметра для этого promotions.Find здесь.
То же самое и с LeaderRouter, поэтому позвольте мне перейти к файлу leaderRouter.js.
И в LeaderRouter также,
здесь, где вы найдете leaders.Find с пустым объектом JavaScript.
Вместо этого замените это на этот
req.query, чтобы параметры запроса были переданы.
Таким образом, это то, где мы будем передавать в Рекомендуемом столбце
через как параметр запроса.
Теперь, скорректировав эти два, давайте теперь поработаем над маршрутом блюда,
поэтому перейдя в файл dishRouter.js, даже в DishRouter, то же обновление здесь.
Итак, перейдя к этим блюдам.Find в методе get здесь, измените это на req.query.
Таким образом, мое обновление DishRouter было завершено.
Таким образом, мы теперь обновили PromorOuter, ReaderRouter и
DishRouter, то мы перейдем к обновлению этого FavoriterOuter.
Теперь вы бы реализовали любимый маршрутизатор как часть вашего
четвертого задания.
Теперь в FavoriterOuter вы увидите, что для
FavoriterOuter я не показываю вам оставшийся партер, потому что
вы должны были сделать как часть вашего задания.
Позвольте мне сначала обратить ваше внимание на метод get для
Favoriterouter.route («/:dishid').
Теперь я собираюсь использовать этот метод get,
чтобы просто проверить, что конкретное блюдо с
DishID уже является любимым для пользователя.
Поэтому вместо того, чтобы просто сказать, что операция GET не поддерживается,
я просто собираюсь использовать наличие этой операции get.
А потом мы скажем, «
Избранные».
И я скажу,
пользователь: req.user.id,
поэтому мы найдем избранное для этого конкретного пользователя.
А потом мы скажем, «Фавориты».
И, поймать (((err),
следующий (err)).
И тогда аналогичным образом здесь, мы добавим в ошибку здесь.
Далее (err)), вот.
Так что внутри это.then, когда мы получим избранное,
то мы проверим, если (! избранное).
Итак, если нет фаворитов для этого пользователя,
то, очевидно, блюдо, которое мы проверяем, не существует.
Так что мы вернёмся, Res.StatusCode, 200.
SetHeader ('Content-Type
'' приложение/json ').
И тогда мы вернемся,
говоря, «существует»: ложь.
Итак, что мы указываем здесь, это то, что если get делается
на эту конечную точку с помощью DishID, этот флаг существует здесь
будет установлен в true, если это блюдо является частью моего избранного.
Если это блюдо не является частью моего избранного, я установлю флаг exists на false.
Итак, здесь вы видите, что, поскольку у меня нет фаворитов, поэтому
существует должен быть автоматически ложным на данный момент.
Так что мы скажем «существует»: false, и тогда мы вернем избранное, здесь.
Ну, очевидно, в этом случае
фавориты будут нулевыми в данный момент, в противном случае.
Таким образом, это означает, что избранное не является нулевым, поэтому мы скажем, если,
(favorites.dishes .indexOf),
поэтому мы будем искать req.params.
Дишид, так что мы собираемся обыскать это.
Favorites.Dishes.Array, чтобы увидеть, существует ли блюдо там.
И если его не существует, очевидно, это вернет отрицательный индекс здесь.
Так что в этом случае я вернусь точно так же, как и здесь.
Поэтому, если он возвращает отрицательный индекс,
то это означает, что даже если у этого конкретного пользователя есть фаворит центра.
Это конкретное блюдо не существует в списке его или
ее любимого, поэтому он вернется существует false здесь.
Теперь в противном случае это означает, что блюдо существует в списке любимых.
Таким образом, в этом случае я верну код состояния 200 существует.
Таким образом, когда пользователь выполняет операцию get в
этой конечной точке с помощью /favorite/dishid.
Там, где в качестве параметра указан DishID.
В качестве параметра записей здесь,
то мы проверим, существует ли это блюдо в избранном.
Если ни один из фаворитов не существует для этого пользователя, то мы вернем существующее false.
Аналогично, если фавориты существуют,
но это конкретное блюдо не существует в избранном, то оно вернет ложное.
В противном случае он вернет истину.
Таким образом, этот флаг существует может быть использован моим клиентом,
чтобы проверить, является ли это блюдо частью списка любимых блюд для этого пользователя или нет.
Наконец, мы обновим файл users.js.
Теперь в файле users.js, нам нужно добавить в
другое поле router.options здесь, потому что
иногда Post запрос, как вы видели с логином,
мы отправим параметры сначала проверить, особенно с автомобилями,
будет ли почтовый запрос разрешен.
Вот почему они проверяют машины, машины с опциями здесь и потом.
Мы просто вернем
сообщение о состоянии 200 в ответ на это.
Таким образом, для любой конечной точки под пользователями, если мы получили
параметры просто вернет статус 200 здесь.
Теперь функция Login, которую мы реализовали ранее.
Мы просто сделали pasport.authenticate («локальный») здесь, а
затем мы проверяем остальные значения здесь.
Теперь этот passport.authenticate ('local'), если пользователь не
проходит проверку подлинности, он просто возвращает несанкционированный в ответном сообщении.
Теперь это может быть не очень значимым для
клиентской стороны, чтобы отобразить эту информацию.
Поэтому мы усовершенствуем этот метод входа в систему маршрутизатора
таким образом, что аутентификация будет возвращать более значимую информацию в этой части.
Чтобы сделать это, мы не собираемся делать паспорт,
удостоверяющий личность внутри здесь.
Вместо этого мы возьмем, поэтому позвольте мне удалить это оттуда,
и тогда вы увидите, как я буду обновлять сообщение маршрутизатора здесь.
Итак, мы увидим автомобилиWithOptions.
А потом мы включим рек, рез и следующий здесь.
И внутри req, res, и
следующий здесь, passport.authenticate,
Мы назовем это с «локальным».
Теперь, когда мы вызываем это с локальным, если
возникает ошибка аутентификации, passport.authenticate может быть сделан, чтобы
вернуть значение ошибки, а также он вернет пользователя, если нет ошибки.
И это может быть параметр, называемый info,
который будет нести дополнительную информацию, которая может быть передана обратно пользователю.
Эта ошибка будет возвращена, когда есть подлинная ошибка, которая возникает
в возможности для проверки подлинности.
Но если информация пользователя отправляется в passport.authenticate, но
пользователь не существует, то это не считается ошибкой.
Вместо этого он будет считаться, как пользователь не существует.
И эта информация передается обратно в инфообъект, который входит.
Таким образом, ошибка будет возвращена, когда есть подлинная ошибка, которая возникает во время
процесса проверки подлинности.
Но информация, они будут содержать информацию, если пользователь не существует, и поэтому
passport.authenticate передает обратно сообщение о том, что пользователь не
существует или либо имя пользователя неправильное, либо пароль неверный.
И так далее, чтобы информация была передана в информационном сообщении.
Теперь мы увидим, как это полезно для нас, когда посмотрим на клиентскую сторону
немного позже.
Таким образом, в этой ситуации
мы будем обрабатывать это следующим образом.
И не только это, когда мы называем этот паспорт аутентифицировать,
нам также нужно передать в (req, res,
next), как это три параметра полосы.
Так вот структура.
Когда вам нужно вызвать аутентификацию паспорта,
ожидайте, что он передаст вам такую информацию в качестве метода обратного вызова здесь.
Таким образом, вам также нужно предоставить этот req, res следующий прямо там тоже.
Теперь, если это произойдет.
Так что мы скажем, если (err).
Поэтому, если возникает ошибка,
мы скажем, return next (err), а затем пусть
обработчик ошибок нашего экспресс-маршрутизатора позаботится об этом.
Теперь рассмотрим другие ситуации.
Если (! ), поэтому если мы достигли этой точки, то это означает, что это
не ошибка, которая произошла, но вместо этого, возможно, пользователь не может быть найден.
Если пользователь не найден, то пользователь здесь будет установлен в null в этом случае.
Таким образом, в такой ситуации, если пользователь не существует,
то нам нужно иметь возможность передавать информацию обратно на сторону сервера.
Итак, что мы будем делать, это мы передадим эту информацию в этом формате,
так что я собираюсь вырезать это отсюда, а
затем вставить его сюда, а затем мы будем редактировать так.
Если пользователь равен нулю, то мы отправим обратно statusCode
401, что означает несанкционированный, а
затем мы отправим обратно информацию об успехе, false.
И тогда мы не будем передавать токен назад, мы передадим сообщение о состоянии.
Итак, здесь мы скажем логин, Неудачный.
И тогда третья информация передаст эту информацию, этот
объект, который мы получили здесь в качестве третьей части
этого ответного сообщения, которое мы отправляем обратно с нашего сервера здесь.
Таким образом, флаг успеха будет сброшен на false.
Статус будет установлен Login Unscessed и информация об ошибке,
которая передается в информации, будет передана обратно.
Теперь обратите внимание, что эта ситуация произойдет, если либо имя пользователя и
пароль неверны.
И поэтому это не ошибка, в смысле ошибки, но тот факт, что аутентификация
не смогла найти ни пользователя, ни пароля пользователя, является неправильным.
Таким образом, информация будет закодирована в притоке, который приходит, и так,
что я передам обратно как ошибку на мою клиентскую сторону.
В противном случае часть
обрабатывается как req.login.
Поэтому, если это успешно,
passport.authenticate добавит к пользователю этот метод req.login.
Таким образом, в этот момент мы просто передадим в объект пользователя, который мы получили.
Итак, если мы достигли этой точки,
то это означает, что объект пользователя не является нулевым, а
также не произошла ошибка, так что это означает, что
пользователь может войти в систему, и поэтому мы будем говорить err.
Таким образом, он попытается войти в систему пользователя.
Так что скажем, если ошибаешься.
И тогда мы передадим обратно ту же информацию об ошибках, что мы сделали здесь.
Поэтому в этом случае, если ошибка.
Если ошибка, то мы передадим код состояния 401, и
мы скажем, успех ложный, а статус - Вход Неудачный.
И тогда информация об ошибке, которую
мы передадим, так как вместо
информации, которую мы передадим, не может войти в систему пользователя.
Таким образом, это сообщение, которое будет передаваться здесь, если произойдет ошибка.
В противном случае, мы были бы внизу.
И поэтому в этот момент мы сможем сгенерировать токен.
Поэтому, если мы достигли этого момента, это означает, что пользователь
успешно вошел в систему, и поэтому теперь мы можем сгенерировать токен.
Таким образом, мы будем генерировать токен на основе идентификатора пользователя, а
затем мы передадим этот токен обратно пользователю.
Итак, здесь мы скажем токен var.
И тогда мы можем сказать res.statusCode = 200, а затем res.json (успех) верно,
что означает, что пользователь успешно вошел в систему.
И поэтому статус будет логин успешно, а
затем третья часть вместо ошибки я передам токен обратно пользователю.
Итак, мы скажем токен, токен,
этот токен, который мы только что получили ранее, так что токен будет передан
в качестве свойства токена сообщения rip light.
Итак, обратите внимание, что эта ось установлена в true.
Таким образом, это означает, что пользователь успешно вошел в систему.
И поэтому пользователь может продолжить движение вперед на этом этапе.
И это должно быть сделано внутри req.Login здесь.
Таким образом, в этот момент мы закроем req.Login.
Поэтому обратите внимание, что это внутри этого req.Login здесь.
Так что там мы передадим этих троих назад.
Поэтому позвольте мне просто отстукнуть порог трех строк в.
И так мы будем обрабатывать логин пользователей.
Опять же, просмотрев этот код еще раз.
Таким образом, мы сделаем сообщение маршрутизатора, но
вместо того, чтобы аутентифицировать паспорт прямо там, мы скажем req, res,
next, а затем внутри здесь мы сделаем паспорт.authenticate для локального.
И эта аутентификация будет передана обратно, поэтому мы можем предоставить функцию обратного вызова для этого.
И эта функция обратного вызова вернет либо ошибку, пользователя, либо
информацию здесь.
И поэтому, если он делает ошибку, мы просто позволим обработчику экспресс-ошибок
позаботиться об этом.
Если пользователь имеет значение null, то это означает, что вход пользователя был неудачным,
и причина этого будет в информации, чтобы вернуться в качестве
информационной ошибки в сообщении плана здесь.
Если мы подойдем к этому моменту, то пользователь успешно проверен.
Таким образом, мы войдем в систему пользователя.
Таким образом, passport.authenticate добавит в этот метод под названием Login в
сообщение запроса, поэтому мы можем вызвать логин с пользователем, и
если это возвращает ошибку, то мы вернем ошибку здесь соответствующим образом.
Если нет, то мы достигли бы точки, где пользователь успешно
аутентифицирован, поэтому они могут генерировать веб-токен JSON здесь и вернуть
веб-токен JSON пользователю, чтобы подтвердить, что пользователь успешно вошел в систему.
Так что это набор шагов, которые мы будем использовать здесь.
Теперь причина, по которой я делаю более сложный способ обработки, заключается в том, что я хочу
различать ситуацию, когда происходит подлинная ошибка во время
процесса приложения, в отличие от ситуации, когда имя пользователя недействительно
или пароль недействителен.
Таким образом, эти два случая будут обрабатываться этой ситуацией, когда информация будет
нести информацию обратно к нам.
Таким образом, это не ошибка, но это ситуация, когда
пользователь не является действительным пользователем или пароль пользователя недействителен.
Вот как они будут обрабатывать процесс входа пользователя в систему.
Кроме того, я добавлю еще один метод здесь, называемый
CheckJwToken.
Вполне возможно, что, хотя клиент вошел в систему и
получил веб-токен JSON, через некоторое время срок действия веб-токена JSON может истечь.
И поэтому, если пользователь пытается получить доступ с клиентской стороны с истекшим токеном
к серверу, сервер не сможет аутентифицировать пользователя.
Таким образом, с периодическими интервалами мы можем провести перекрестную проверку, чтобы убедиться, что
веб-токен JSON по-прежнему действителен.
Вот почему я включаю другую конечную точку под названием
CheckJwtToken, поэтому, если вы доберетесь до CheckJwtToken.
Включая токен в заголовок авторизации,
этот вызов вернет true или false, чтобы указать вам,
остается ли веб-токен JSON действительным или нет.
Если он недействителен, то клиентская сторона может инициировать другой логин для
пользователя, чтобы получить новый веб-маркер JSON, если это необходимо.
Итак, чтобы сделать это, мы скажем cors, CorsWithOptions и,
req, res, здесь, как и ожидалось.
И здесь мы скажем,
passport.authenticate ('jwt',
И, {session: false}).
И это вернет ошибку, пользователя, информацию.
Вспомните, как мы использовали аутентификатор Passport ранее.
Таким образом, сессия JWT падает здесь.
Так что ранее здесь мы говорим, паспорт.аутентифицировать местный.
Таким образом, это для локальной аутентификации.
Таким образом, это для аутентификации веб-токенов JSON.
Поэтому, когда мы называем это, так как это будет проверять веб-токен JSON,
поэтому я скажу, если (err), верните следующий (err).
А затем пусть обработчик ошибок Express позаботится об этой ситуации.
И тогда мы скажем, если (! ),
Если пользователь не существует, то аналогично, иначе.
Таким образом, это означает, что если объект пользователя был найден из веб-маркера JSON, а
затем загружен в req.user, то это означает, что пользователь является действительным пользователем.
И так можно позволить двигаться вперед.
В противном случае, мы собираемся сказать, что пользователь не существует.
Поэтому нам нужно сделать вывод, что веб-токен JSON истек.
Итак, на данный момент мы отправим res с кодом состояния
401, таким образом, несанкционированным.
SetHeader (, 'Content-Type',
'application/json').
И тогда мы вернем res,
.json, скажем, {status:,
'JWT invalid! '.
И тогда мы вернем флаг под названием success: false.
И затем, Мы вернем информацию, которую мы
получаем, если пользователь не аутентифицирован как ошибка в этот момент.
В противном случае это означает, что мы достигаем этой точки, когда пользователь является действительным пользователем.
Поэтому в этом случае позвольте мне просто скопировать этот код здесь,
мы отправим код состояния 200, а
затем res.json отправит JWT,
действительный! , и успех будет правдой.
И в третьей части мы отправим информацию о пользователе.
Таким образом, когда эта конечная точка вызывается
с помощью метода get, это проверит, является ли токен действительным или нет.
Если токен действителен, то вы получите этот ответ.
И из флага успеха в ответе
вы можете проверить, является ли веб-токен JSON действительным или нет.
И это полезно на стороне клиента.
Теперь этот паспорт здесь, passport.authenticate здесь,
должен быть снабжен req и res в качестве двух параметров здесь.
Так вот как мы называем этот паспорт.authenticate.
Обратите внимание, что всякий раз, когда вы вызываете pasport.authenticate и
ожидаете эту функцию обратного вызова здесь, вам нужно добавить эту точку, req,
.res, к этому паспорту. authenticate, а затем вернуться сюда.
Таким образом, мы обновили все на стороне сервера.
Итак, давайте сохраним все изменения на стороне сервера.
Итак, теперь наш сервер готов
обрабатывать входящие запросы от нашего углового клиента.
С этим мы завершаем это упражнение.
В этом упражнении мы подготовили наш Express сервер для
обработки входящих запросов от нашего углового клиента.
В следующем упражнении мы рассмотрим клиента Angular более подробно, чтобы
понять, как он взаимодействует с этим дополнительным сервером.
Это хорошее время для вас сделать Git фиксацию с сообщением,
интегрируя клиента и сервера.
[ МУЗЫКА]