Это вторая часть упражнения «Экспресс-сеансы».
Мы завершили первую часть ранее,
где мы добавили поддержку Express
Sessions и используем Express Sessions как способ отслеживания пользователей на стороне сервера
и распознавания входящих запросов от пользователей.
В этом упражнении мы не концентрируемся на самих экспресс-сессиях,
но мы рассмотрим способ расширения нашего экспресс-сервера REST API
для поддержки новой модели регистрации и аутентификации пользователей.
Итак, мы представим новую пользовательскую модель и схему в нашем приложении. У
нас уже есть маршрут пользователей косой черты, который
экспресс-генератор уже смонтировал маршрутизатор пользователя.
Итак, мы собираемся использовать это, а затем обновить
его для поддержки регистрации новых пользователей,
аутентификации существующего пользователя,
а также выхода пользователя с нашего сайта сервера.
Итак, мы рассмотрим Express Sessions как способ отслеживания пользователей после входа пользователя в систему,
а затем, когда пользователь выходит из системы,
сеанс будет удален из системы.
Итак, как мы будем делать это расширение в этом упражнении?
Пойдем и выясним.
Продолжая наш экспресс-REST API сервер,
давайте теперь перейдем к моделям и добавим новый файл с именем user.js.
Это файл, в котором мы создадим пользовательскую схему и модель.
Мы создадим простую схему пользователя, которая отслеживает имя пользователя и пароль,
а также флаг, который установлен, чтобы указать,
является ли пользователь администратором или обычным пользователем.
Таким образом, это один из способов различения между различными типами пользователей.
Итак, в этом файле
давайте сначала требуем Mongoose, потому что мы создаем схему Mongoose,
а затем мы создадим схему с именем Mongoose,
а затем мы скажем var user.
Так что это пользовательская схема, которую мы собираемся создать,
и мы скажем новую схему пользователя.
Схема пользователя будет определена, как я только что упомянул,
с тремя полями здесь называемыми username,
которые, очевидно, будут иметь строку типа,
и это обязательное поле,
и это уникальное поле.
Вы не хотите, чтобы два пользователя с одинаковым именем пользователя в вашей системе,
поэтому мы создаем имя пользователя, а затем второе поле - поле пароля.
Теперь, конечно, вы можете расширить
эту схему пользователя, чтобы позволить пользователю отслеживать весь свой профиль,
но мы сделаем это в одном из последующих упражнений, на данный момент
пользователь распознается в системе просто именем пользователя и паролем.
Таким образом, пароль имеет строку типа, а затем является обязательным.
Третье поле, которое я собираюсь использовать, называется admin.
Таким образом, администратор имеет тип Boolean,
и мы скажем по умолчанию false.
Таким образом, по умолчанию при создании пользователя создается
новый пользователь,
флаг администратора будет установлен в false.
Вы можете явно установить его в true из
вашего кода, чтобы пометить пользователя как административного пользователя.
Возможно, вы можете предоставить дополнительные привилегии администратору
или, возможно, разрешить администратору выполнять
определенные операции, которые обычные пользователи не будут делать этого.
Мы рассмотрим, что в одном из последующих упражнений,
на данный момент, это пользовательская схема, которую мы создали,
давайте создадим из этого модуля модуль и экспортируем из
этого модуля модель Mongoose имени пользователя.
Итак, это модель Mongoose, а схема -
пользовательская схема, которую мы только что определили немного раньше.
Итак, вот как мы определяем нашу пользовательскую схему.
Итак, теперь, когда мы определили нашу пользовательскую схему,
давайте перейдем в маршрутизатор, который уже был настроен
экспресс-генератором, когда он генерирует это экспресс-приложение.
Итак, если вы заходите в папку маршрутов,
вы увидите этот файл под названием users.js.
Таким образом, этот файл users.js будет расширен для создания маршрутизатора.
Итак, прямо там, что я собираюсь сделать, это импортировать body-парсер,
а затем они объявят экспресс-маршрутизатор,
а затем мы скажем также импортировать
пользовательскую схему и
модель от пользователя моделей,
а затем для экспресс-маршрутизатора мы скажем,
маршрутизатор использует анализатор тела.
Итак, теперь, когда мы объявили парсер тела там,
мы собираемся оставить эту часть как таковая,
позже мы изменим это, чтобы позволить администратору
иметь возможность получить
всех пользователей, которые зарегистрированы в системе, но на данный момент,
мы собираемся оставить этот маршрут как таковой.
Мы добавим здесь еще несколько маршрутов,
так что скажем: «Сообщение маршрутизатора».
Таким образом, мы будем поддерживать пост-операцию на маршруте, называемом
signup, и, как вы ожидаете,
этот маршрут регистрации позволит пользователю зарегистрироваться в системе, так что это будет поддерживать регистрацию пользователя.
Итак, мы скажем: «Рек, рес, следующий».
Таким образом, это будет регистрация роутера после регистрации,
остальные методы не будут разрешены в конечной части регистрации.
Таким образом, чтобы получить доступ к
этому, поскольку этот маршрутизатор пользователей установлен на косой черты пользователей,
мы бы указывали эту конечную точку как косая черта пользователей регистрации,
и это конечная точка, которая будет использоваться для регистрации новых пользователей в системе.
Итак, первое, что мы будем делать, это использовать
пользовательский метод, и ожидание заключается в том, что для пользователя, чтобы зарегистрироваться,
имя пользователя и пароль будут предоставлены в виде строки JSON
внутри тела входящего почтового запроса.
Итак, из тела,
поскольку тело уже было бы проанализировано парсером тела,
поэтому из тела
сначала проверит, чтобы убедиться, что
пользователь с этим именем пользователя не существует в системе.
Если пользователь с этим именем пользователя существует,
вы пытаетесь зарегистрировать дублирующегося пользователя
, и это не должно быть разрешено в системе.
Итак, мы скажем: «Пользователи находят одного», а затем попытаемся найти,
есть ли один пользователь с именем пользователя,
выбранным клиентом, который пытается зарегистрировать нового пользователя.
Если пользователь уже существует,
то, очевидно, вы не позволите новому пользователю зарегистрироваться с тем же именем пользователя.
Итак, мы скажем: «Тогда пользователь».
Таким образом, это вернет пользователя здесь и внутри этого пользовательского поля,
тогда мы проверим, существует ли пользователь,
а затем позвольте мне поймать ошибку здесь.
Итак, мы скажем: «Лови ошибку», а затем «Следующая ошибка».
Итак, мы просто передадим это обработчику ошибок там.
Итак, если этот поиск для пользователя возвращает поле пользователя,
если пользователь не равен нулю.
Таким образом, если пользователь, возвращаемый этим поиском,
не является нулевым, то это означает, что пользователь с данным именем пользователя уже существует,
поэтому вы не должны допускать повторную регистрацию.
Так что мы скажем: «Вар ошибается новая ошибка».
И мы скажем: «Пользователь req. body username».
Уже существует. Таким образом, в основном
вы предотвращаете регистрацию дублирующего пользователя, а затем мы скажем
err.status 403 против запрещенного, а затем выходите,
вызывая обработчик ошибок, следующий ошибка. В
противном случае это означает, что пользователь не существует,
поэтому вы должны разрешить пользователю быть подписаны.
Итак, в части else,
скажем, верните user.create ().
Мы создадим нового пользователя с именем пользователя, установленным в req.body.username,
а затем позвольте мне поместить это в следующую строку, чтобы это было более понятным для вас,
и мы скажем пароль: req.body.password.
Теперь мы уже знаем, что флаг администратора по умолчанию будет установлен в false,
поэтому мы собираемся оставить его как таковой,
и это позволит нашему новому пользователю зарегистрироваться, и когда новый пользователь зарегистрирован,
это вернет обещание и внутри «тогда» мы будем обрабатывать это обещание здесь.
Итак, это вернет обещание от
этого «тогда», а затем мы справимся с этим в следующем «тогда» здесь.
Скажем тогда, res.statusCode 200,
res.SetHeader, и мы скажем, контент-тип приложения/json,
и мы скажем, res.json (статус: Регистрация Успешная)
, и если вы хотите,
мы можем загрузить пользователя в
это ответное сообщение здесь как свойство в json.
Будет сказано, что регистрация прошла успешно.
Тогда, если есть ошибка в
этой операции, будет говорить «next err».
Таким образом, это обработает ошибку.
Если обещание не разрешится успешно,
то будет обработано этим. Так вот и всё.
Итак, здесь у нас есть способ для пользователя зарегистрироваться.
Таким образом, для того, чтобы пользователь зарегистрировался,
пользователь будет делать сообщение в/users/signup, а в теле сообщения
клиент будет включать строку json
с именем пользователя и свойствами пароля в этой строке json.
Вот как вы регистрируетесь для нового пользователя.
Теперь давайте посмотрим, как мы будем входить в систему пользователя.
Теперь мы по-прежнему будем использовать экспресс-сеансы, которые мы сделали ранее, чтобы отслеживать пользователя.
Таким образом, для регистрации пользователь скажет «router.post» в конечной точке/логине.
Таким образом, на конечной точке /login
мы сделаем router.post.
Мы, очевидно, вместо того, чтобы говорить функцию,
вы можете использовать функцию стрелки здесь для router.post,
я собираюсь сделать то же самое здесь.
Я увлекался функциями стрелок.
Итак, мы сделаем функцию стрелки здесь.
Итак, для входа, как происходит логин?
Поэтому для входа в систему,
что мы будем делать, это то, что мы перейдем к файлу app.js, а затем внутри этого auth,
мы делали эту регистрацию для пользователя там.
То, что я собираюсь сделать, так это я собираюсь скопировать
все это, потому что я бы не стал делать все это в любом случае.
Итак, позвольте мне скопировать весь путь с этого момента до req.session.user.
Итак, если часть req.session.user я собираюсь скопировать,
а затем перейти к users.js и для входа в систему.
Это именно то, как я собираюсь сделать аутентификацию.
Поэтому мы скажем, если не req.session.user.
Таким образом, это означает, что пользователь еще не аутентифицировал себя.
Затем вы ожидаете, что обычная проверка подлинности
в качестве механизма для использования пользователем для проверки подлинности.
Поэтому мы скажем var AuthHeader, если! AuthHeader, то мы поднимем ошибку, в
противном случае мы получим имя пользователя и пароль из заголовка.
Теперь, здесь мы делали, если имя пользователя равно admin и пароль равен паролю.
Но теперь, что мы собираемся сделать, это мы будем искать в
базе данных, чтобы увидеть, существует ли этот конкретный пользователь.
Итак, вместо этого делать здесь,
вместо того, чтобы делать это, если имя пользователя и пароль,
мы скажем, user.findone,
и мы скажем, имя пользователя является именем пользователя.
Таким образом, это свойство равно этому имени пользователя, которое мы только что получили,
а затем мы скажем, тогда пользователь.
Так что внутри этого «тогда».
Поэтому я собираюсь переместить этот код внутри этого «тогда», потому
что теперь то, что я собираюсь проверить, теперь, когда я получил пользователя,
мне нужно проверить, чтобы убедиться, что этот пользователь именно то, что я ищу.
Поэтому на этом этапе
мы собираемся сначала проверить, чтобы убедиться, что пользователь не является нулевым.
Таким образом, мы скажем, если пользователь равен нулю.
Итак, если пользователь равен нулю, это
означает, что мы не смогли найти пользователя с этим конкретным именем пользователя.
Таким образом, вам нужно будет вернуть ошибку здесь.
Поэтому позвольте мне просто скопировать эту часть, а затем вставить ее
здесь, а затем мы вернемся, говоря var new Error,
и мы скажем,
имя пользователя пространства
не существует.
Поэтому в этом случае
этот пользователь не существует, поэтому я просто собираюсь удалить эту часть, а
затем соответствующий статус ошибки будет 403 здесь.
Итак, это первая часть.
Если пользователь равен нулю, то мы, очевидно, собираемся сказать, что пользователь не существует.
Вторая часть, которую мы собираемся проверить, - Else если пароль пользователя.
Таким образом, это означает, что пользователь существует в данный момент.
Итак, вторая проверка, которую мы сделаем, заключается в том, что пароль пользователя не
равен паролю.
Нам снова нужно указать ошибку там.
Таким образом, ошибка будет заключаться
в том, что в этом случае мы скажем
«ваш пароль неверен».
Итак, это вторая часть.
Таким образом, ваш пароль неверный, а затем последняя часть.
Мы скажем «иначе».
Поэтому позвольте мне отступить этот код.
Итак, иначе, если user.username
является именем пользователя, которое, очевидно, должно быть истинным в этом случае.
Затем вторая часть
user.password равна паролю, который также, очевидно, должен быть правильным в этот момент.
Но в любом случае,
я собираюсь проверить эту проблему здесь, и это еще не произойдет вообще в этом случае.
Итак, к тому времени, когда вы достигнете этой точки,
имя пользователя должно быть
таким же, как имя пользователя и пароль должен быть таким же, как пароль,
но в любом случае я поставил двойную проверку в этот момент, чтобы быть вдвойне уверен.
Затем в этом случае
мы скажем, req.session.user аутентифицирован.
Таким образом, мы установим это на аутентификацию,
а также этот, мы скажем
res.StatusCode 200.
Таким образом, мы смогли успешно аутентифицировать пользователя.
Итак, мы скажем res.statusCode 200, а затем мы скажем res.SetHeader
Content-Type text plain и
res.end, мы просто отправим сообщение с надписью «Вы аутентифицированы».
Вот оно. Таким образом, это охватывает тогдашнюю часть пользователя Findone.
Итак, во-первых, мы проверяем, что если пользователь равен нулю, это
означает, что мы не смогли найти пользователя,
поэтому мы, очевидно, возвращаем ошибку, говорящую, что имя пользователя не существует.
Если пароль пользователя не совпадает с паролем,
поэтому на данный момент
пользователь существует, но пароль не совпал, поэтому мы скажем:
«Ваш пароль некорректен», а затем, наконец,
мы достигнем этого момента, тогда имя пользователя и пароль должны быть правильно идентифицированы.
Хотя мне не нужна эта проверка, но я просто поместил ее туда, а затем на этот момент,
я установлю req.session.user для
его аутентификации, а затем установлю код состояния на 200, что означает, что вы
успешно смогли аутентифицировать пользователя, а затем вы можете закончить на этом этапе.
Поскольку это то,
я поставлю улов в этот момент,
поэтому мы скажем ошибку catch, и если ошибка возникает,
то я просто передам
ошибку следующему, чтобы обработчик ошибок мог справиться с ошибкой соответствующим образом.
Так что заканчивает этот пользователь Findone.
Теперь это тот случай, когда req.session.user не установлен.
Если это уже установлено,
то это означает, что пользователь уже вошел в систему.
Поэтому в этом случае
другая часть здесь касается ситуации, когда мы установим
StatusCode на 200,
а Content-Type на text/plain, а затем мы скажем:
«Вы уже прошли проверку подлинности».
Итак, если вы достигнете этой другой части,
вы бы пришли сюда, потому что req.session.user уже не является нулевым,
поэтому это
означает, что пользователь уже прошел аутентификацию, поэтому, когда вы
достигнете этой точки, пользователь уже вошел в систему ранее,
поэтому вам не нужно проверять.
Таким образом, вы просто скажете:
«Вы уже прошли проверку подлинности», а затем закончите на этом этапе.
Хорошо. Итак, теперь последний метод, который мы будем реализовывать, - это выход пользователя.
Итак, мы сделаем router.get on /logout.
Вам должно быть интересно, почему мы делаем выход
на выход, а не сообщение, которое мы сделали при входе в систему?
При входе в систему необходимо указать имя пользователя и пароль.
Для выхода из системы вы просто выходите из системы,
поэтому вам не нужно предоставлять какую-либо дополнительную информацию, потому что
сервер уже отслеживает вас на основе
вашего идентификатора сеанса и внутри этого сеанса cookie здесь.
Поэтому нам не
нужно явно отправлять любую дополнительную информацию в теле сообщения.
Поэтому мы скажем, если req.session так, что это означает, что сеанс должен существовать
, в противном случае вы пытаетесь выйти из системы пользователя, который не вошел в систему.
Так что это не имеет смысла.
Теперь сам сеанс предоставляет этот метод,
называемый destroy, и когда вы вызываете метод destroy,
сеанс уничтожается, и информация удаляется с
серверной стороны, относящейся к этому сеансу.
Таким образом, это означает, что если клиент попытается снова отправить
информацию о сеансе, которая хранится в
виде подписанного файла cookie на стороне клиента,
это будет недействительным.
Поэтому нам нужен метод удаления cookie, который хранится на стороне клиента.
Теперь эта операция удалит
информацию о сеансе со стороны сервера, так что сеанс больше не действителен.
Итак, на данный момент
мы скажем req.session.destroy, а затем мы скажем, res.clearCookie.
Таким образом, ClearCookie - это способ попросить клиента
удалить файл cookie, а имя cookie - идентификатор сеанса.
Итак, в предыдущем упражнении
мы видели, что файл cookie хранится с именем идентификатора сеанса на стороне клиента.
Поэтому мы просим клиента удалить этот файл cookie со
стороны клиента в ответном сообщении, а затем мы скажем,
res.redirect, и мы перенаправим его на главную страницу здесь.
Таким образом, это способ перенаправления пользователя для входа на их стандартную страницу,
так, например, домашнюю страницу вашего приложения.
Таким образом, вы будете обрабатывать выход из системы.
Если req.session не существует,
это означает, что вы не вошли в систему,
поэтому нам придется сгенерировать ошибку.
Таким образом, мы скажем var err,
new Error, «Вы не вошли в систему»,
и мы установим статус ошибки в 403,
это запрещенная операция, а
затем генерируем ошибку в обработчике ошибок, вот и все.
Итак, теперь вы видите, что мы расширили маршрутизатор пользователя для поддержки трех новых конечных точек,
конечной точки регистрации, которая позволяет пользователю зарегистрироваться,
конечной точки входа, которая позволяет зарегистрированному пользователю
войти в систему, а затем конечной точки выхода, которая позволяет зарегистрированному пользователю выйти из системы.
В процессе выхода из системы
вы уничтожаете сеанс на стороне сервера,
вы также очищаете файл cookie на стороне клиента,
так что клиент не может быть использован в истекшем сеансе, чтобы попытаться связаться с этим сервером.
Одно незначительное исправление в users.js,
это должно быть var User require.. /models/user,
помните, что файл users.js находится в папке маршрутов, а затем
файл user.js находится
в папке моделей, которая находится на одном уровне, а затем в папке моделей.
Так что, это должно быть.. /models/user,
поэтому сделайте это незначительное исправление, вот и все.
Мы изменили файл users.js,
теперь последнее, что нам нужно сделать, это пойти и исправить файл app.js.
В файле app.js приложения,
если вы перейдете в файл app.js,
вы увидите, что у нас есть
этот индекс косой черты здесь и косой черты пользователей здесь после проверки подлинности.
Теперь это не сработает для нас, потому что если вам нужно зарегистрироваться,
то пользователь зарегистрируется и войдет в систему до подтверждения авторизации,
в любом случае, если регистрация и вход предназначены для процесса регистрации,
поэтому я собираюсь переместить их до шага аутентификации здесь.
Итак, мы переместим это в это место.
Таким образом, входящий пользователь может получить доступ к индексному файлу
в косой черте, а также получить доступ к конечной точке пользователей без проверки подлинности
, но любая другая конечная точка,
пользователь должен быть аутентифицирован,
так что именно так мы настроили это.
Внутри аутентификации функции мы скажем:
«Если не req.session.user», то обратите внимание, что это место,
мы бы не позволили пользователю войти сюда без входа пользователя.
Итак, если не req.session.user,
то мы просто скажем, что вы не аутентифицированы.
Эта аутентификация должна быть выполнена с помощью метода входа в систему здесь.
Итак, я собираюсь удалить всю эту часть здесь.
Итак, мы скажем, если не req.session.user,
мы скажем, что вы не аутентифицированы, и поэтому нам придется отправить фотографию три здесь,
так что это означает, что вы никогда не должны спуститься
в этот момент вообще без входа пользователя.
Итак, мы скажем, что вы не аутентифицированы.
Напомним, что вам нужно аутентифицироваться, выполнив POST
в конечной точке входа пользователей косой черты.
Таким образом, мы скажем, что вы не аутентифицированы, в противном случае,
если req.session.user равен,
напомним, что в функции входа в
users.js мы установили для следующего пользователя сеанса строку, прошедшую проверку подлинности.
Итак, это то, что мы будем проверять.
Скажем, если req.session.user аутентифицирован,
мы скажем далее, иначе вы не аутентифицированы снова.
Тогда мы отправим обратно запрещенное сообщение. Вот оно.
Таким образом, с этим обновлением
мой файл app.js также готов.
Теперь, сделав эти обновления,
давайте пойдем и проверим, как работает наше приложение сейчас.
Переход к терминалу,
если ваш сервер работает, остановите его, а затем перезапустите сервер.
Мой сервер в данный момент не работает,
поэтому я скажу npm start,
и мой сервер должен быть запущен и запущен.
Давайте теперь посмотрим, как мы получим доступ к серверу.
Отправляясь в Почтальон, позвольте мне сделать GET на
localhost: 3000/блюда, а затем вы сразу увидите
, что он жалуется, что вы не аутентифицированы.
Очевидно, я здесь не аутентифицирован.
Позвольте мне попробовать получить доступ только к локальному хосту: 3000, и вы увидите,
что, этот корень доступен для нас.
Теперь, конечно, мы хотим сначала зарегистрировать пользователя, а затем войти в систему
как пользователь, а затем получить доступ к остальным конечным точкам REST API.
Итак, во-первых, позвольте мне зарегистрировать пользователя.
Чтобы зарегистрировать пользователя,
мне нужно сделать POST для локального хоста: 3000/пользователей/регистрация.
Для этого сообщения POST
в теле сообщения
мне нужно включить в тело
сообщения строку JSON с именем пользователя.
Итак, позвольте мне войти в систему, а
затем я просто использую пароль в качестве пароля.
Это действительная регистрация.
Итак, когда я регистрируюсь как пользователь с
этой информацией в виде строки JSON, включенной в тело сообщения,
позвольте мне увидеть, что заголовок теперь содержит приложение типа содержимого,
JSON, потому что я установил JSON в теле
сообщения, а затем отправляю POST в регистрацию.
Затем, когда я отправляю POST на регистрацию,
вы сразу увидите, что возвращается сервером здесь.
Итак, вы видите, что сервер вернулся, сказав:
«Регистрация успешно» и сам,
он дает мне сведения о пользователе здесь.
Итак, это запись, которая существует в моем MongoDB, и
обратите внимание, что тип модели - это тип пользовательской модели, который мы установили.
Таким образом, у нас есть имя пользователя и пароль и
флаг администратора, как вы можете видеть установлен в false по умолчанию.
После того, как мы зарегистрируем пользователя,
этот пользователь теперь является действительным пользователем.
Итак, позвольте мне попробовать снова POST того же пользователя и посмотреть, что произойдет.
Итак, когда я POST того же пользователя, очевидно,
там со стороны сервера,
он отвечает, что этот пользователь уже существует.
Таким образом, вы можете видеть, что мы настроили нашу процедуру регистрации, чтобы не позволить
пользователю дублировать регистрацию с тем же идентификатором пользователя.
Хорошо. Итак, это вторая часть.
Теперь давайте сделаем логин пользователя.
Чтобы сделать логин пользователя,
позвольте мне удалить тип содержимого, а затем я также
удалю тело, потому что для входа, это не требуется.
Итак, я ничего не заполняю в
заголовке, а затем пытаюсь войти, и когда я попытался войти в систему,
он отвечает, говоря, что вы не аутентифицированы.
Ты неавторизован.
Теперь мне нужно войти в систему.
Итак, здесь я могу использовать базовую аутентификацию.
Итак, в базовой аутентификации
я просто собираюсь ввести свое имя пользователя и
пароль, которые я только что зарегистрировал на предыдущем шаге, а затем обновить свой запрос,
а затем выполнить POST при входе в систему.
Итак, когда я делаю POST при входе в систему,
вы видите, что сервер отвечает: «Вы аутентифицированы».
Таким образом, на этом этапе
я могу выполнять
запросы GET, PUT, POST и DELETE на всех остальных конечных точках.
Итак, на данный момент, если я сделаю GET на конечной точке блюд,
вы увидите, что это возвращает
пустое поле, потому что моя база данных в настоящее время пуста.
Позвольте мне очистить авторизацию, а также из заголовка удалить
авторизацию, а затем сделать GET, и это окно инструментов просто отлично.
Итак, вы можете видеть, что теперь я могу
получить доступ к конечным точкам, потому что я вошел в систему.
Итак, теперь позвольте мне сделать выход пользователя.
Итак, скажем, localhost: 3000 и выход из системы.
Обратите внимание также, что в
файлах cookie файл cookie был установлен в идентификаторе сеанса прямо там.
Итак, этот файл cookie существует на моем клиентском сайте.
Итак, теперь позвольте мне выйти из системы, сказав GET localhost: 3000/пользователей/выход.
Итак, когда я делаю выход из пользователя,
вы сразу увидите, что я перенаправлюсь на
эту локальную конечную точку: 3000, а также заметите, что файл cookie исчез.
Итак, когда я смотрю на файлы cookie,
вы видите, что localhost,
файл cookie пропал, потому что с моей серверной стороны, когда я делаю выход,
он отправляет обратно чистый cookie на клиентскую сторону, и поэтому cookie пропал.
Теперь, если я попытаюсь сделать GET
на локальном хосте: 3000/dises,
это не будет работать, потому что я не аутентифицирован.
Таким образом, это демонстрирует вам, как вы можете расширить ваш Express сервер,
чтобы позволить пользователям регистрироваться самостоятельно, а затем разрешить пользователю войти в систему,
а затем выйти из системы.
На стороне сервера вы отслеживаете зарегистрированного пользователя, используя сеанс и используя
cookie на стороне клиента, и когда пользователь
выходит из системы, cookie уничтожается на стороне клиента.
С этим мы завершаем это упражнение.
Это хорошее время для вас, чтобы сделать фиксацию Git,
с сообщением, экспресс-сессии часть вторая.