Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

WEB 5 Ибрагимова Шакиров

.docx
Скачиваний:
14
Добавлен:
14.09.2022
Размер:
944.67 Кб
Скачать

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ФАКУЛЬТЕТ ИНФОРМАТИКИ И РОБОТОТЕХНИКИ

КАФЕДРА ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ

УТВЕРЖДАЮ

Проректор университета по научной работе

ФИО

"___" ______________ _______г.

Лабораторная работа № 5

«Cookie, сессии и авторизация в веб-приложении»

по предмету: Web-технологии

Преподаватель

Б.С. Юдинцев

Исполнители

К.Б. Ибрагимова

А.Р. Шакиров

Уфа 2021

ЗАДАНИЕ

  1. Создать модель аккаунта для регистрации пользователя.

  2. Создать страницу регистрации пользователя. Пароль зарегистрированного пользователя должен храниться в БД в хешированном виде.

  3. Создать страницу авторизации пользователя и реализовать механизм доступа к REST API и странице с формой только для авторизированных пользователей, используя сессии и cookie.

ТЕОРЕТИЧЕСКИЙ МАТЕРИАЛ

HTTP Basic Authentication

HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространённой схемой HTTP авторизации является "Basic" (базовая) авторизация.

Опишем общий механизм HTTP авторизации. Протокол передачи гипертекста RFC 7235 определяет средства HTTP авторизации, которые может использовать сервер для запроса у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом 401 (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок WWW-Authenticate (en-US), содержащий хотя бы один метод авторизации. Клиент, который хочет авторизоваться, может сделать это, включив в следующий запрос заголовок Authorization с требуемыми данными. Обычно, клиент отображает запрос пароля пользователю, и после получения ответа отправляет запрос с пользовательскими данными в заголовке Authorization. В случае базовой авторизации, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.

OAuth

OAuth — открытый протокол (схема) авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. Для улучшения защиты может быть использована аутентификация в два шага (например, Google Authenticator), когда для подтверждения задействуется другой сервис пользователя (например, когда для аутентификации на веб-сайте требуется ввести кодовое слово, отправляемое на мобильный телефон).

Ключевая особенность применения OAuth заключается в том, что, если пользователь имеет хорошо защищённый аккаунт, то с его помощью и технологии OAuth он может пройти аутентификацию на других сервисах, и при этом ему не требуется раскрывать свой основной пароль.

JSON Web Token

JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON. Как правило, используется для передачи данных для аутентификации в клиент-серверных приложениях. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности.

ХОД РАБОТЫ

Регистрация аккаунта

В соответствии с параметрами модели создадим шаблон страницы с веб формой регистрации (/register) представленный на рисунке 1.

Рисунок 1. Форма регистрации

Создадим роутер register.js, обрабатывающий запрос на получение страницы и запрос на создание пользователя (рис.2) и обработчик запроса создания пользователя (рис.3).

Рисунок 2. Роутер register.js

Рисунок 3. Обработчик запроса создания пользователя

Авторизация аккаунта

Для авторизации аккаунта пользователя создадим шаблон формы (/login) представленный на рисунке 4.

Рисунок 4. Форма авторизации

Создадим роутер login.js, обрабатывающий запрос на получение страницы и запрос на авторизацию пользователя (рис.5) и обработчик запроса авторизации пользователя (рис.6).

Рисунок 5. Роутер login.js

Рисунок 6. Обработчик запроса авторизации пользователя

Добавим промежуточную функцию валидации сессии пользователя (рис.7).

Рисунок 7. Валидация сессии пользователя

Проверка функций авторизации

Проведем проверку API в Insomnia (рис.8-9).

Рисунок 8. Проверка авторизации

Рисунок 9. Cookie хранилище в Insomnia

Проверим содержание cookie-файлов в хранилище браузера после проведения авторизации (рис.10).

Рисунок 10. Cookie хранилище браузера

ВЫВОД

В ходе выполнения лабораторной работы были получены навыки создания модели аккаунта для регистрации пользователя, страницы регистрации пользователя и страницы авторизации пользователя, был реализован механизм доступа к REST API и странице с формой только для авторизированных пользователей, используя сессии и cookie.