[MUSIC]
Сервер Express REST API, который мы реализовали в предыдущем
модуле, позволяет любому пользователю выполнять любые операции GET или POST или DELETE.
Отсутствует контроль над тем, кто может выполнять эту операцию.
Это означает, что
если вы запускаете такой сервер, то любой может войти на ваш сервер и
начать манипулировать информацией, которая присутствует в вашей базе данных.
Очевидно, что это опасная ситуация.
Способ, которым должен быть реализован сервер, заключается в том, что
вам нужно иметь какое-то ограничение на то,
какие типы пользователей будут разрешены для выполнения каких видов операций.
Поэтому, возможно, вы разрешите и
авторизованному пользователю только выполнять операции GET.
Так, например, если вы хотите, чтобы гость мог видеть информацию
о блюдах в вашем ресторане или меню вашего ресторана и
так далее, это вполне приемлемо.
Но вы можете разрешить только администратору войти и
изменить информацию о блюде или удалить блюдо из меню.
А также обновите существующее блюдо в меню, или акцию,
или информацию о лидерах на вашей стороне сервера.
Теперь вы также можете иметь другую группу пользователей, которые будут зарегистрированы пользователи,
которым может быть разрешено сохранить некоторые из своих блюд в качестве своих любимых блюд,
и только они смогут манипулировать списком своих любимых блюд.
Таким образом, это еще один уровень авторизации или
аутентификации, который вам нужно выполнить.
Таким образом, у вас есть разные классы пользователей, а
также, в зависимости от того, какие операции им разрешено выполнять.
Таким образом, все это означает, что вам нужна какая-то безопасность, которая будет
встроена в вашу серверную сторону.
Мы рассмотрим, как мы можем аутентифицировать пользователей, а
затем определим, какой пользователь этот клиент.
И затем, в зависимости от типа пользователя,
вы можете позволить пользователю выполнять определенные виды операций.
Мы начнем с базового понимания этого, что мы называем
обычной аутентификацией на стороне сервера для
клиента, а затем, основываясь на этом во всем остальном модуле.
И тогда в конце этого модуля мы получим механизм
, тем самым позволяя пользователям регистрироваться самостоятельно.
И зарегистрированные пользователи могут выполнять определенные операции
, которые незарегистрированный пользователь не может, и так далее.
Таким образом, мы будем накладывать
различные виды контроля доступа для различных операций на стороне сервера на основе типа пользователя.
Таким образом, это задает вам перспективу, или,
скорее, представление о том, что вы столкнетесь в этом модуле.
Начнем с обычной аутентификации,
самого базового механизма, который позволит нам аутентифицировать пользователей.
Обычная аутентификация в HTTP - это очень простой механизм,
который будет запрашивать у пользователя имя пользователя и
пароль, которые будут отправлены с запросом.
И есть определенная структура
о том, как эта информация будет передаваться от клиента на серверную сторону.
Таким образом, это вопрос, основная аутентификация доступа, которую поддерживает HTTP,
это вопрос, который позволит серверу оспорить клиента и попросить
имя пользователя и пароль, которые будут отправлены клиентом.
Таким образом, сервер может вызвать клиента для проверки подлинности, введя эту
информацию.
Клиент должен отправить имя пользователя и
пароль в ответ на вызов со стороны сервера.
Таким образом, каждое сообщение запроса, исходящее от клиента,
должно включать закодированную форму имени пользователя и
пароля в заголовке запроса, который идет от клиента на сторону сервера.
Поэтому, когда сервер получает запрос,
сервер извлечет эту информацию из заголовка запроса клиента.
И затем используйте это для аутентификации клиента, прежде чем
разрешить доступ к различным операциям на стороне сервера.
Итак, как работает эта аутентификация?
Если клиент отправляет запрос на сервер, и
этот запрос клиента не включает формирование авторизации, сервер
будет оспаривать клиента, он просит клиента отправить эту информацию.
Сервер бросает вызов клиенту,
включив заголовок в входящее ответное сообщение.
Заголовок с типом как WWW-Authenticate, а
затем вторая часть, где он указывает тип, где он будет
указывать, какой тип проверки подлинности клиент должен отправить.
И мы начнем с понимания базовой аутентификации здесь.
А также обратите внимание, что ответное сообщение будет содержать код ошибки 401,
который является несанкционированным, что означает несанкционированный.
Поэтому, когда ответ возвращается с серверной стороны, клиент
в ответ на этот ответ приходит, клиент должен будет отправить свой запрос,
включая конкретное поле заголовка в сообщении запроса авторизации типа.
И это поле заголовка авторизации будет содержать некоторую информацию.
Для базовой аутентификации, эта информация будет в форме,
как первое слово здесь, будет Basic.
И затем следует пробел здесь, а затем строка в кодировке Base64 здесь.
Эта кодированная строка Base64 кодирует имя пользователя и
пароль в определенном формате, а затем включает в заголовок.
Теперь вы говорите, что если вы отправляете сообщение запроса, подобное этому,
включая это, в заголовке, тогда кто-нибудь посередине.
Так что если вы знаете что-нибудь о безопасности и о том,
как люди в середине атаки могут быть запущены, то очевидно, что
это может быть извлечено злоумышленником между ними,
а затем может быть использовано для подделки реального клиента.
Опять же, в данный момент мы не будем вдаваться в этот вопрос.
Когда я расскажу о HTTPS в следующем модуле,
я вернусь, чтобы рассмотреть эту проблему немного более подробно.
Но на данный момент информация в заголовке будет отправлена
без шифрования в заголовке в данный момент.
Теперь еще одна причина, по которой я это делаю, заключается в том, что мы можем фактически посмотреть
на заголовок напрямую, а затем увидеть эту информацию в самом заголовке.
Таким образом, когда клиент отправляет этот запрос, сервер извлечет
информацию из этого заголовка авторизации в заголовке запроса.
Затем используйте эту информацию, чтобы проверить, является ли это
авторизованным запросом клиента или нет.
Теперь, конечно, ваш следующий вопрос будет:
что именно содержит этот заголовок авторизации?
Сам заголовок авторизации строится следующим образом.
Если у вас есть имя пользователя и пароль, это две
части информации, которые вы будете использовать для аутентификации клиента.
Таким образом, имя пользователя и пароль будут объединены в одну строку,
сказав имя пользователя и двоеточие, а также сам пароль.
Таким образом, строка имени пользователя, двоеточие и
пароль будут объединены вместе в целую строку здесь.
Эта результирующая строка, которую мы получаем здесь, кодируется с помощью кодирования Base64.
Если вы знаете о том, как кодирование выполняется основы для кодирования,
преобразуйте его в заголовок ASCII, как показано в этом примере,
так что это не что иное, как строка заголовков ASCII.
Теперь, если вы мало знаете о базовой жесткой кодировке, не беспокойтесь об этом,
это не влияет на ваше понимание того, что здесь происходит.
Таким образом, эти строки в кодировке Basic64, поэтому
эта конкретная информация кодируется в такую строку, а
затем заключена в заголовок запроса, идущий от клиента на сервер.
Сам заголовок запроса имеет тип авторизации,
а затем фактическое значение здесь, которое говорит:
Basic, и пробел здесь, и строка в кодировке Base64 здесь.
Таким образом, когда это будет получено нашим сервером, сервер извлекает эту информацию,
а затем извлекает имя пользователя и пароль,
а затем проверяет, соответствует ли это авторизованному пользователю или нет на стороне сервера.
Чтобы помочь вам лучше понять, как мы на самом деле организуем экспресс-приложение
и как осуществляется сама аутентификация, как мы узнали ранее,
сами экспресс-приложения организованы в набор промежуточного программного обеспечения.
И способ работы экспресс-приложения заключается в том, что промежуточное программное обеспечение
применяется к запросу и ответному сообщению
в том порядке, в котором оно объявлено в моем экспресс-приложении.
Поэтому, если у вас есть express.use, а
затем у вас есть первый, говорящий на статическом сервере, затем после этого
у вас есть другое промежуточное программное обеспечение, а затем у вас есть другое промежуточное программное обеспечение.
Последовательность, в которой они объявлены в файле app.js express
servers, это точная последовательность, в которой будет применено промежуточное программное обеспечение.
Таким образом, входящий запрос с серверной стороны, как вы вспоминаете в своем
экспресс-приложении, входящий запрос рассматривается как объект запроса.
Объект ответа - это то, что создает экспресс-сервер, а
затем следующий позволяет перейти к следующему промежуточному программному обеспечению
, которое вы собираетесь применять, и так далее.
Итак, входящий запрос, подобный этому, когда он приходит, применяется первое промежуточное программное обеспечение.
И затем, как только это промежуточное программное обеспечение преобразовало как запрос
, так и ответ, оно переходит к следующему промежуточному программному обеспечению, которое затем применяется к нему.
Например, мы увидели, что сначала применили Морган,
затем применили парсер тела к промежуточному программному обеспечению.
Таким образом, они, должно быть, уже преобразовали запрос и объекты ответа.
И после этого мы можем включить промежуточное программное обеспечение аутентификации на месте.
Промежуточное программное обеспечение аутентификации будет аутентифицировать запрос.
Теперь, поэтому, если вы используете обычную аутентификацию, ваш запрос
должен содержать в заголовке заголовок авторизации, который там находится.
Таким образом, заголовок авторизации будет извлечен промежуточным программным обеспечением аутентификации,
а затем проверен, чтобы увидеть, авторизован ли пользователь.
И если промежуточное программное обеспечение аутентификации обнаруживает, что вы авторизованный пользователь,
вам будет разрешено перейти к следующему набору
промежуточного программного обеспечения, который следует за шагом аутентификации.
И ваши записи будут обработаны последующим промежуточным программным обеспечением.
Но с другой стороны,
если ваше промежуточное программное обеспечение аутентификации решит, что вы не являетесь авторизованным пользователем,
то промежуточное программное обеспечение аутентификации приведет вас по другому пути.
А затем сгенерировать ошибку, а затем отправить
соответствующий ответ об ошибке на эту клиентскую сторону и
будет перенаправлен в обработчик ошибок.
Таким образом, это перенаправление в обработчик ошибок будет сделано путем вызова Next
с ошибкой в качестве параметра для этого Next здесь.
Таким образом, Next именно это Next, что мы видим в ресурсе запроса Next здесь.
И поэтому это приведет вас к обработчику ошибок,
который будет обрабатывать ошибку, а затем отправлять сообщение об ошибке обратно на клиентскую сторону,
указывая на сбой аутентификации.
Таким образом, ваша типичная базовая авторизация или обычная
аутентификация работает в вашем серверном приложении.
Поняв это, давайте перейдем к упражнению, где мы
будем реализовывать базовую аутентификацию в нашем приложении и
посмотрим, как она аутентифицирует пользователей.
[ МУЗЫКА]