Время для третьего задания в этом курсе.
В этом модуле мы очень подробно изучаем аутентификацию пользователей.
Теперь, в этом назначении,
мы будем работать дальше над аутентификацией пользователей.
Мы добавим еще одну категорию учетных записей под названием Admin.
Учетная запись администратора — это супер учетная запись, которая
имеет множество привилегий для выполнения различных операций.
Обычная учетная запись пользователя может выполнять только определенные операции на нашем сервере.
Аналогичным образом, незарегистрированный запрос, поступающий от клиента
, который не вошел в систему, может выполнять только определенные операции на нашем сервере.
Теперь мы собираемся изменить наш сервер таким образом
, чтобы получить операции могут выполняться кем угодно.
Вам не нужно входить в систему для выполнения операций get
на различных конечных точках API остального, кроме отправки комментариев.
Для остальных операций на остальных конечных точках API,
операций ввода и удаления POST,
они будут выполняться только администраторами,
обычный пользователь не может выполнять эти операции.
Очевидно, что вы не хотите, чтобы обычный пользователь отправлял новые блюда или рекламные акции,
или информацию лидера, или изменял существующую информацию
или даже удалял эту существующую информацию.
Это должно быть привилегией только системного администратора для нашего сервера.
Также мы позаботимся о том, чтобы обычный пользователь мог
оставлять комментарии о конкретных блюдах, что является приемлемым.
Аналогичным образом, обычный пользователь может обновлять и удалять комментарии, которые он опубликовал.
Другие пользователи или даже администратор не могут обновлять или удалять комментарии, размещенные другим пользователем.
Итак, это еще одно ограничение, которое мы собираемся разместить на нашем сервере.
Теперь давайте продолжим и рассмотрим, как мы собираемся
реализовать это и как именно наш сервер выполняет эти операции.
Прежде всего, я проиллюстрирую вам, как вы
могли бы создать учетную запись администратора в вашей системе.
Вы поймете, что мы должны пойти за
кулисами, чтобы создать учетную запись администратора просто потому, что
мы не хотим, чтобы учетная запись администратора была создана путем выполнения
операции регистрации на наших пользователей/учетной записи регистрации.
Это сделает наш сервер уязвимым для атак.
Таким образом, учетная запись администратора может быть создана
за кулисами только путем прямого доступа к базе данных.
Итак, давайте посмотрим, как мы делаем
это на иллюстрации, которую я покажу вам сразу после.
Теперь, чтобы проверить нашу базу данных,
позвольте мне запустить Mongo Ripple в командной строке,
а затем перейти в папку путаницы, а затем позвольте мне
проверить пользователей, зарегистрированных в моей базе данных в данный момент.
Итак, вы можете видеть, что у меня зарегистрирован только один пользователь.
Итак, позвольте мне создать две дополнительные учетные записи:
один для обычного пользователя,
а другой, который будет администратором.
Таким образом, мы зарегистрируем администратора и второго пользователя также из нашей точки регистрации,
после чего они вернутся в Mongo Ripple, а затем настроили учетную запись администратора
явно, изменив запись в нашей базе данных.
Перейдя к Postman pin,
позвольте мне зарегистрировать двух дополнительных пользователей.
Итак, мы ранее зарегистрировали одного пользователя с этим именем,
поэтому я собираюсь зарегистрировать другого пользователя в моей системе,
и, таким образом, второй пользователь теперь успешно зарегистрирован.
Теперь позвольте мне также зарегистрировать учетную запись администратора.
Итак, для учетной записи администратора
я настрою имя пользователя как admin, а затем зарегистрирую пользователя администратора.
Итак, мы видим, что мы добавили в нашу систему два новых аккаунта.
Отправляясь в Mongo Ripple,
позвольте мне снова повторить
db.user.find () и позвольте мне сделать это довольно, чтобы его было легче читать.
Итак, когда я это делаю,
вы можете видеть, что у нас есть учетная запись администратора здесь с именем пользователя в качестве администратора.
Игнорируйте имя и
фамилию, я установлю это имя и фамилию, чтобы они были одинаковыми для всех трех.
Затем у нас есть другая учетная запись пользователя, которую я установил с именем пользователя здесь,
и третья учетная запись пользователя, которую мы уже имели в нашей базе данных.
Итак, теперь у нас есть три учетные записи
пользователей; две учетные записи пользователей здесь
и учетная запись администратора.
Теперь, конечно, вы увидите, что в учетных записях пользователей
у нас есть этот флаг, называемый флагом администратора, который установлен в false для
любой учетной записи, которая зарегистрирована на этой конечной точке /users/signup.
Это способ настройки учетных записей по умолчанию.
Вы не можете разрешить пользователю настраивать учетную запись администратора
, выполняя что-либо непосредственно на конечной точке API.
Вместо этого мы пойдем за кулисы, а затем в Mongo Ripple,
я собираюсь изменить эту запись для пользователя администратора,
сказав db.users.update, а затем
мы предоставим имя пользователя как admin здесь.
Итак, мы собираемся обновить запись стиха, а затем мы скажем {$set:
вспомните, как мы манипулировали MongoDB, поэтому мы
скажем {$set: {"admin»: «true»}.
Итак, то, что мы делаем здесь, это то, что мы
ищем эту учетную запись пользователя с именем пользователя admin,
а затем мы устанавливаем флаг admin true
здесь, используя параметр $ set.
Таким образом, мы бы обновили учетную запись, чтобы быть учетной записью администратора.
Итак, вы видите, что это изменило результаты.
Итак, давайте еще раз проверим счета.
Теперь, когда вы проверяете учетную запись,
вы увидите, что для учетной записи
администратора флаг администратора теперь установлен в true,
так что вы в конечном итоге создадите учетную запись администратора.
Теперь учетная запись администратора, как мы ожидали, имеет дополнительные привилегии.
Таким образом, как только вы завершите это задание,
вы заметите, что операция получения может быть выполнена любым пользователем на
/dishes/dishes/specificdishendpoint/promotiones/specificpromotionendpoint и аналогичным образом,
для лидеров в пунктах также.
Но
операции POST, put и delete на этих конечных точках могут выполняться только администраторами.
Теперь, кроме того, комментарии конечной точки,
мы позволили бы только зарегистрированному пользователю, который вошел в систему для
доступа к комментариям для конкретного блюда,
мы позволим зарегистрированному пользователю публиковать комментарии.
Мы уже настроили это в упражнении, поэтому,
когда пользователь отправляет комментарий,
мы гарантировали, что мы проверяем
подлинность пользователя, а затем, когда комментарий опубликован,
мы установили идентификатор автора для комментария, используя идентификатор пользователя.
Итак, мы уже закончили это.
Но теперь, кроме того,
для операций ввода и удаления комментариев
только пользователю, который отправил конкретный комментарий, будет
разрешено делать операции ввода и удаления над своими комментариями.
Любой другой пользователь не может изменить чужие комментарии.
Аналогично, даже администратор не может изменить чужие комментарии
или удалить чужой комментарий.
Итак, это вторая часть этого задания, что ты будешь делать.
Третья часть заключается в том, что администратор может запросить
конечную точку /users и запросить список зарегистрированных пользователей,
ни один другой обычный пользователь не может сделать этот запрос.
Итак, это другое ограничение, которое мы введем туда.
Теперь, чтобы убедиться, что пользователь является администратором,
мы сначала проверим, что пользователь является зарегистрированным пользователем.
Таким образом, функция проверки пользователя, которую мы уже реализовали в
authenticate.js, должна применяться даже там, где вам нужно проверить наличие администратора.
Во-первых, вы проверяете, что является проверенным пользователем, затем
вы вводите другую функцию под названием VerifyAdmin в
файле authenticate.js, которая будет проверять, что пользователь является администратором.
Теперь, чтобы проверить, является ли пользователь администратором,
все, что вам нужно сделать, это проверить rec.user, который находится
на объекте запроса rec.user,
проверьте, является ли флаг администратора истинным или нет.
Если флаг admin истинный,
вы разрешите нормальный процесс дальнейшего продвижения к [неслышному] произойдет.
Если пользователь не является администратором,
вы создадите ошибку и отправите сообщение об ошибке обратно на клиентскую сторону.
Итак, вот как мы будем обрабатывать учетную запись пользователей администратора.
Теперь, когда пользователь пытается изменить или удалить свои собственные комментарии,
мы должны проверить, чтобы убедиться, что автор комментария тот
же, что и пользователь, который пытается изменить комментарий.
Теперь у rec.user также есть поле ID,
поэтому вам нужно проверить это с полем автора комментария.
Если эти два совпадают,
то вы разрешите пользователю выполнять операции ввода или удаления.
Если они не совпадают,
вы не разрешите операции ввода или удаления для этого конкретного комментария.
Так что это другой аспект, который вы собираетесь
реализовать как часть вашего третьего задания.
Давайте посмотрим, как все эти вещи работают
с помощью Postman для выполнения различных операций на нашем сервере.
Возвращаясь к Postman,
позвольте мне сначала выполнить операцию GET на
блюдах, чтобы просто проверить, что находится в моей базе данных.
Итак, если я выполняю операцию GET на блюдах,
обратите внимание, что я не помещаю никакой аутентификации в заголовок.
Операция GET разрешена кем угодно.
Итак, когда я выполняю операцию GET,
я вижу, что у меня уже есть одно блюдо с комментарием, уже существующим в этом блюде.
Этот комментарий уже был опубликован этим пользователем.
Итак, у нас уже есть одно блюдо в системе.
Так что, это прекрасно,
я собираюсь удалить блюдо.
Теперь, чтобы удалить блюдо,
очевидно, что операция не может быть выполнена обычным пользователем.
Итак, позвольте мне войти как,
чтобы вы могли видеть, что я регистрируюсь как обычный пользователь.
Итак, позвольте мне войти в систему как обычный пользователь.
Поэтому, когда я войду в систему, я получу токен.
Итак, я собираюсь скопировать этот токен и сохранить его.
Теперь, когда у меня есть мой токен,
позвольте мне выполнить операцию DELETE на блюдах.
Итак, когда я перехожу к операции DELETE.
Итак, позвольте мне выбрать этот GET, а затем выполнить операцию DELETE с посудой.
В заголовке позвольте мне включить авторизацию здесь, и вы заметите,
что, когда мы вставляем запрос, а затем отправляем авторизацию DELETE,
вы заметите, что он немедленно возвращается с этим сообщением здесь,
как вы можете видеть в предварительном просмотре,
он говорит: «Вы не уполномочены выполнить эту операцию! «
Тогда код ошибки 403 запрещен.
Таким образом, это сообщение, сгенерированное
функцией VerifyAdmin, которое вы собираетесь реализовать в рамках этого упражнения.
Таким образом, если пользователь не является администратором,
то это сообщение, которое будет
генерировать ваш VerifyAdmin, и это не позволит запросу выйти за пределы этой точки.
Итак, вы можете видеть, что я закрыл операцию DELETE.
Итак, как ты это делаешь?
В вашем коде вы видели, что для применения VerifyUser
мы устанавливаем Authenticate.verifyUser в
операциях POST, PUT и DELETE.
Теперь вы можете связать промежуточное ПО один за другим.
Таким образом, мы можем сказать Authenticate.VerifyUser запятая,
а затем после этого вы можете сказать Authenticate.VerifyAdmin,
чтобы применить VerifyAdmin сразу после VerifyUser.
Таким образом, если вы хотите, чтобы операция была ограничена только администратором,
вы сначала выполняете часть VerifyUser, а затем сразу после этого
применяете промежуточное программное обеспечение VerifyAdmin.
Сразу после этого. Итак, если эти две проверки
успешно пройдут, то вы перейдете к выполнению операции.
Если проверка VerifyAdmin завершилась неудачей,
вы вернете это сообщение об ошибке, как вы видите
здесь, а затем прервите операцию этой части.
Таким образом, вы вернете следующую ошибку из своего VerifyAdmin,
если пользователь не является администратором.
Итак, я продемонстрировал вам, как вы собираетесь
использовать учетную запись пользователей администратора для ограничения операций PUT
, POST и DELETE.
То же самое, операции POST и PUT также не будут разрешены ни на одной из этих n частей.
Теперь позвольте мне продемонстрировать другой аспект здесь.
Итак, вы видели, что там,
когда мы выполняем операцию GET,
вы видели, что уже есть комментарий, который был опубликован именем пользователя Jogesh,
первого пользователя, который находится в моей системе.
Теперь я собираюсь войти в систему как другой пользователь.
Итак, я войду в свой второй аккаунт, который является Muppala, а затем, когда я вхожу в систему,
я снова получаю токен.
Итак, позвольте мне взять этот жетон здесь.
Позвольте мне скопировать этот жетон.
Теперь, что я собираюсь сделать, это сделать, я сделаю GET на блюдах localhost.
Итак, позвольте мне сделать GET на блюдах localhost, чтобы показать вам конкретный комментарий внутри здесь.
Итак, этот конкретный комментарий с этим идентификатором.
То, что я собираюсь сделать, так это то,
что я скопирую удостоверение тарелки.
Я также собираюсь скопировать идентификатор комментария отсюда, и я собираюсь выполнить
операцию DELETE на этом конкретном блюде
и напомнить, что у нас есть косая
черта комментариев, а затем этот конкретный идентификатор комментария.
Теперь помните, что этот комментарий был опубликован этим именем пользователя,
но теперь я вошел в себя как другой пользователь с другим именем пользователя.
Итак, когда я сейчас выполняю операцию DELETE с помощью другой учетной записи,
вы сразу заметите, что здесь написано:
«Вы не уполномочены удалять этот комментарий! «
Тогда он говорит 403, то же самое.
Если вы попытаетесь выполнить операцию PUT для этого конкретного комментария, зарегистрированного в качестве другого пользователя
, он скажет: «Вы не уполномочены обновлять этот комментарий!»
Таким образом, как PUT, DELETE и UPDATE чужого комментария не разрешены.
Итак, теперь позвольте мне войти в качестве администратора в этот момент, а затем позвольте мне попытаться удалить этот
конкретный комментарий, и вы увидите, что будет сгенерировано одно и то же сообщение.
Таким образом, администратор также не может удалять или обновлять чужие комментарии.
Итак, чтобы войти в качестве администратора,
позвольте мне войти в POST здесь, а затем позвольте мне войти в качестве администратора.
Теперь помните, что эти токены будут действительны в течение 33,600 секунд.
Таким образом, вы можете сохранить эти три токена, которые вы генерируете для трех пользователей.
Таким образом, вам не нужно продолжать входить в систему как этот конкретный пользователь.
Пока вы используете правильный токен в заголовке,
ваши операции будут выполнять просто отлично идентифицируя трех разных пользователей.
Итак, позвольте мне войти в качестве администратора здесь.
Поэтому, когда я вхожу в качестве администратора,
я получаю токен здесь.
Итак, я собираюсь скопировать и сохранить этот токен.
Просто помните, какой токен принадлежит кому, когда вы делаете копию этого.
Теперь, возвращаясь к этому, удалите операцию комментария.
Я собираюсь войти в заголовок, а затем я собираюсь изменить это на токен для
администратора, а затем попытаться выполнить ту же операцию DELETE, а затем вы видите,
что даже администратор не уполномочен удалять комментарий, размещенный другим пользователем.
Это вполне приемлемо.
Но давайте попробуем удалить тот же комментарий,
этим пользователем, который создал этот
комментарий, и вы увидите, что это может быть успешно сделано.
Итак, давайте выполним эту операцию.
Поэтому, чтобы сделать это, я собираюсь вернуться и получить токен, который у
меня есть для первого пользователя, а затем изменить поле Авторизация.
Теперь, для этой операции DELETE,
я собираюсь изменить это на носителя,
а затем это токен для первого пользователя с именем пользователя Jogesh.
Поэтому, когда я попытаюсь удалить этот комментарий,
вы заметите, что комментарий теперь успешно удален.
Таким образом, как вы можете видеть из шагов,
комментарий может быть удален только пользователем, который создал этот комментарий.
Теперь, следующий шаг,
когда мы делаем операцию DELETE на тарелке,
мы видели ранее, что если мы сделали операцию DELETE как обычный пользователь,
вы получаете сообщение с надписью:
«Вы не уполномочены выполнять эту операцию!»
Итак, я собираюсь изменить этот токен на токен администратора, а затем
показать вам, что администратор может выполнить операцию DELETE на блюдах и горшочке.
Итак, перейдя в этот запрос,
позвольте мне изменить токен на токен для пользователя администратора.
Таким образом, когда я выполняю операцию DELETE как пользователь администратора,
вы заметите, что операция DELETE
успешна, а затем ответите обратно с сообщением здесь.
Теперь, когда я делаю GET на конечной точке блюд,
вы заметите, что операции GET показывают, что мои блюда были опущены.
Теперь другая операция, которую вы также будете реализовывать в этом назначении,
заключается в том, что мы можем сделать операцию GET на конечной точке пользователей косой черты.
Таким образом, когда вы выполняете операцию GET на конечной точке пользователей,
вы заметите, что если вы не являетесь авторизованным пользователем,
он скажет, что вы не уполномочены выполнять эту операцию.
Итак, локальный хост: 3000/пользователи/конечная точка,
теперь вы разрешаете это выполнять только администратор.
Итак, если обычный пользователь,
при входе в систему как обычный пользователь с заголовком,
вам не будет разрешено выполнять эту операцию.
Теперь позвольте мне изменить этот токен на токен
от администратора, а затем вы увидите, что
администратору будет разрешено выполнять эту операцию.
Итак, перейдя к GET,
позвольте мне изменить этот токен на токен для
пользователя администратора, а затем, когда я выполняю операцию GET, он возвращается.
Как вы можете видеть, три пользователя, которые зарегистрированы в моей системе,
он показывает пользователя номер один,
пользователь номер два и пользователь номер три.
Конечно, обратите внимание, что хэш и соль удаляются,
когда сообщение возвращается сервером на стороне клиента.
Таким образом, информация о хэше и соли никогда не будет раскрыта снаружи.
Таким образом, Mongos автоматически позаботится о фильтрации
этой информации, прежде чем он отправит обратно информацию пользователя.
Итак, потому что вы не должны раскрывать
информацию о хэше и соли внешнему миру.
Таким образом, это информация о трех учетных записях пользователей, которая возвращается.
Таким образом, это возвращается только в том случае, если вы выполняете операцию GET
на конечной точке пользователей косой черты в качестве пользователя администратора.
Если вы выполняете тот же запрос, что и любой другой пользователь,
это не будет разрешено.
Таким образом, снова вы проверите сначала
VerifyUser, а затем проверьте VerifyAdmin и только если это администратор,
то эта операция может быть выполнена на этой конечной точке.
Таким образом, это все различные задачи, которые вы будете делать в рамках этого задания.
Подробная информация о том, как это необходимо сделать, документирована в инструкциях по назначению.
Итак, ознакомьтесь с инструкциями, прежде чем приступать к выполнению третьего задания.
Получайте удовольствие, выполняя третье задание.