ЗВІТИ З ЛАБОРАТОРНИХ РОБІТ

з дисципліни «WEB-ОРІЄНТОВАНІ ТЕХНОЛОГІЇ. BACKEND РОЗРОБКИ»
Виконавець: Студент групи ІК-33 — Майстренко Тимофій Валентинович
Фото: Майстренко Тимофій Валентинович

Лабораторна робота №3

З дисципліни: «WEB-орієнтовані технології. Backend розробки»
Тема: «Розробка функціонального REST API. Реєстрація та авторизація користувачів. Валідація даних і обробка помилок»

Мета роботи

Метою лабораторної роботи є вивчення принципів побудови REST API, набуття практичних навичок розробки серверного застосунку з використанням Node.js та Express, реалізація механізмів реєстрації й авторизації користувачів, забезпечення валідації вхідних даних і обробки помилок, а також організація захищеного доступу до ресурсів із використанням JWT-токенів і системи ролей користувачів.

Короткі теоретичні відомості

REST API є архітектурним стилем побудови вебсервісів, який базується на використанні HTTP-протоколу для взаємодії між клієнтом і сервером. Основою REST є робота з ресурсами, кожен з яких має унікальну адресу та підтримує стандартні HTTP-методи, зокрема GET, POST, PUT, PATCH і DELETE.

Одним із важливих принципів REST є Stateless, тобто сервер не зберігає стан клієнта між запитами, а кожен запит має містити всю необхідну інформацію для його обробки. Такий підхід спрощує масштабування системи та робить API більш універсальним.

Для створення серверної частини застосунку у роботі використовується Node.js та фреймворк Express, який дозволяє швидко описувати маршрути, обробляти HTTP-запити, підключати middleware та формувати JSON-відповіді. Для безпечного зберігання паролів використовується бібліотека bcryptjs, а для реалізації авторизації через токени — бібліотека jsonwebtoken.

Валідація даних є важливим етапом розробки API, оскільки дозволяє перевіряти коректність вхідних значень ще до їх потрапляння в бізнес-логіку застосунку. Це запобігає помилкам, дублюванню даних та некоректному використанню сервісу. Для перевірки вхідних даних у роботі використовується express-validator.

Окрему роль у REST API відіграє обробка помилок. Сервер повинен повертати коректні HTTP-коди стану та зрозумілі повідомлення. Наприклад, код 400 використовується для помилкових даних, 401 — для неавторизованого доступу, 403 — для забороненого доступу, 404 — коли ресурс не знайдено, а 500 — у разі внутрішньої помилки сервера.

Постановка задачі

У межах лабораторної роботи необхідно реалізувати функціональний REST API для власного вебзастосунку оренди велосипедів. На відміну від попередньої лабораторної роботи, де основний акцент було зроблено на структурі бази даних і роботі з ORM, цього разу основна увага приділяється автентифікації, авторизації, валідації та захисту маршрутів.

У застосунку потрібно реалізувати:

  • реєстрацію користувача;
  • авторизацію користувача;
  • перевірку коректності вхідних даних;
  • обробку типових помилок;
  • захищені маршрути для авторизованих користувачів;
  • розмежування доступу за ролями;
  • logout;
  • оновлення профілю;
  • зміну пароля;
  • refresh token;
  • обмеження кількості спроб входу;
  • middleware для перевірки токена.

Практична реалізація виконується в межах уже створеного застосунку оренди велосипедів із використанням наявної бази даних bike_rental_db та таблиці users, у якій зберігаються ім’я користувача, email, пароль, роль і дата створення запису.

Опис структури даних

Для реалізації лабораторної роботи використовується таблиця users, яка вже була створена в межах попередньої лабораторної роботи. Ця таблиця містить основні поля, необхідні для реалізації реєстрації та авторизації.

Поле id є первинним ключем і використовується як унікальний ідентифікатор користувача. Поле name містить ім’я користувача. Поле email є унікальним та використовується для авторизації. Поле password зберігає хешований пароль, а не пароль у відкритому вигляді. Поле role відповідає за роль користувача в системі та може набувати значень client або admin. Поле created_at містить дату створення запису.

Таким чином, структура таблиці users дозволяє реалізувати не лише базову реєстрацію, а й розмежування прав доступу до окремих ресурсів системи.

Реалізація REST API

На початковому етапі було створено окремий модуль для маршрутів автентифікації та авторизації. Для цього у проєкті було виділено окремі файли маршрутів, middleware та допоміжні модулі. Такий підхід дозволив зберегти структуру проєкту зрозумілою та розділити логіку за призначенням.

У головному файлі сервера було підключено маршрут /auth, через який реалізується функціональність реєстрації, входу в систему, перегляду профілю, оновлення даних профілю, зміни пароля, logout та оновлення access token. Така організація маршрутів відповідає підходу REST API та робить застосунок більш структурованим.

Для перевірки підключення до бази даних використано Sequelize. Після успішного з’єднання сервер запускається й надає клієнту доступ до API-запитів.

Підключення auth-маршрутів
Рис. 1 Підключення auth-маршрутів у server.js

Реєстрація користувача

Одним із ключових елементів роботи є реалізація маршруту реєстрації нового користувача. Для цього створено маршрут POST /auth/register, який приймає ім’я, email, пароль і підтвердження пароля. Перед створенням користувача система перевіряє коректність вхідних даних, зокрема формат email, мінімальну довжину пароля та збіг пароля з підтвердженням.

Якщо користувач із таким email уже існує, сервер повертає повідомлення про помилку. Якщо дані є коректними, пароль хешується за допомогою bcryptjs, після чого новий користувач зберігається в базі даних. Важливо, що при звичайній реєстрації роль користувача встановлюється як client, щоб уникнути самостійного створення адміністратора.

Реєстрація користувача
Рис. 2 Реалізація маршруту реєстрації

Авторизація користувача

Для входу користувача в систему реалізовано маршрут POST /auth/login. Під час авторизації сервер перевіряє, чи існує користувач із вказаним email, після чого порівнює введений пароль із хешем, збереженим у базі даних.

У разі успішної перевірки сервер генерує два токени:

  • access token — для доступу до захищених маршрутів;
  • refresh token — для отримання нового access token після завершення строку його дії.

Згенерований access token містить у собі ідентифікатор користувача, email, ім’я та роль. Це дозволяє використовувати токен не тільки для підтвердження особи, а й для перевірки рівня доступу.

Авторизація користувача
Рис. 3 Реалізація маршруту логіну

Валідація даних і обробка помилок

Для забезпечення надійності роботи API у проєкті було реалізовано валідацію даних за допомогою бібліотеки express-validator. Під час реєстрації перевіряється заповнення всіх необхідних полів, правильність email, довжина пароля та коректність ролі користувача. Під час логіну перевіряється наявність email і пароля, а також правильність формату email.

У разі некоректних даних сервер повертає статус 400 Bad Request із переліком помилок. У разі відсутності токена або недійсного токена сервер повертає 401 Unauthorized. Якщо користувач не має прав доступу до певного маршруту, повертається 403 Forbidden. Для неіснуючих маршрутів повертається 404 Not Found, а внутрішні серверні помилки обробляються через 500 Internal Server Error.

Окремо було реалізовано логування помилок у консоль сервера, що спрощує налагодження застосунку.

Валідація та обробка помилок
Рис. 4 Приклад валідації та обробки помилок

Захищені маршрути та middleware

Для захисту маршрутів у проєкті було створено middleware authMiddleware, який перевіряє наявність токена в заголовку Authorization, виділяє його зі значення Bearer <token> та перевіряє валідність через jsonwebtoken. Якщо токен є дійсним, інформація про користувача додається до об’єкта req.user, після чого виконується наступний етап обробки запиту.

Також було створено roleMiddleware, який перевіряє роль користувача. Завдяки цьому маршрут /auth/admin доступний лише користувачам з роллю admin. Таким чином у системі реалізовано розмежування доступу на рівні ролей.

Захищеним також є маршрут /auth/profile, через який авторизований користувач може переглядати власні дані.

Middleware перевірки токена
Рис. 5 Реалізація middleware для перевірки токена

Оновлення профілю, зміна пароля та logout

Для користувача було реалізовано додаткові можливості керування обліковим записом. Маршрут PUT /auth/profile дозволяє оновлювати ім’я та email. Перед збереженням нового email система перевіряє, чи не використовується він іншим користувачем.

Маршрут PATCH /auth/change-password дає змогу змінити пароль. Для цього користувач повинен вказати старий пароль, новий пароль та підтвердження нового пароля. Сервер перевіряє правильність старого пароля, після чого зберігає новий хешований пароль.

Маршрут POST /auth/logout реалізує вихід користувача із системи. Під час logout refresh token видаляється зі сховища токенів, після чого його більше не можна використати для оновлення доступу.

Оновлення профілю та logout
Рис. 6 Реалізація оновлення профілю, зміни пароля та logout

Refresh token і обмеження спроб входу

Для підвищення безпеки застосунку реалізовано механізм refresh token. Коли строк дії access token завершується, користувач може отримати новий access token через маршрут POST /auth/refresh, передавши коректний refresh token.

Крім цього, у системі реалізовано обмеження кількості невдалих спроб входу. Якщо користувач кілька разів поспіль вводить неправильний пароль, його обліковий запис тимчасово блокується для нових спроб входу. Такий підхід зменшує ризик brute-force атак та підвищує загальний рівень безпеки застосунку.

Refresh token та обмеження спроб
Рис. 7 Реалізація refresh token і захисту від багаторазових спроб входу

Опис роботи застосунку

У межах лабораторної роботи було вдосконалено серверний застосунок оренди велосипедів, розроблений у попередній лабораторній роботі. Якщо раніше система забезпечувала базову роботу з даними про станції, велосипеди, бронювання та оплату, то тепер у застосунку додано повноцінний механізм автентифікації та авторизації користувачів.

Звичайний користувач має можливість зареєструватися, увійти в систему, переглянути свій профіль, оновити особисті дані та змінити пароль. Адміністратор, крім базових можливостей, має доступ до окремих захищених маршрутів, призначених лише для керування системою.

Після успішної авторизації користувач отримує токени, які використовуються для доступу до захищених маршрутів. Якщо токен недійсний або прострочений, сервер повертає повідомлення про помилку. Якщо користувач намагається отримати доступ до маршруту, який вимагає роль admin, а має роль client, сервер повертає заборону доступу.

Таким чином, у застосунку реалізовано повний базовий цикл роботи з обліковим записом користувача, що є необхідним елементом сучасного REST API.

Результати роботи

У результаті виконання лабораторної роботи було реалізовано функціональний REST API для реєстрації та авторизації користувачів у системі оренди велосипедів. Було створено маршрути для реєстрації, логіну, logout, перегляду профілю, оновлення профілю, зміни пароля та оновлення access token.

У процесі виконання роботи було реалізовано:

  • валідацію вхідних даних;
  • хешування паролів;
  • генерацію JWT-токенів;
  • захист маршрутів через middleware;
  • розмежування прав доступу за ролями;
  • обмеження кількості невдалих спроб входу;
  • базове логування помилок.

Отримані результати показують, що реалізований застосунок відповідає основним вимогам до побудови REST API з автентифікацією та авторизацією користувачів.

Реєстрація
Рис. 8 Успішна реєстрація користувача

Логін
Рис. 9 Успішна авторизація користувача

Профіль
Рис. 10 Отримання профілю авторизованого користувача

Admin route
Рис. 11 Перевірка доступу до маршруту адміністратора

Зміна пароля
Рис. 12 Успішна зміна пароля

Висновок

У ході виконання лабораторної роботи було досягнуто поставленої мети. Було вивчено принципи побудови REST API та реалізовано серверний застосунок на Node.js і Express із підтримкою реєстрації, авторизації, валідації даних, обробки помилок і захисту маршрутів через JWT.

У межах роботи було реалізовано взаємодію з наявною базою даних MySQL, використано ORM Sequelize для роботи з моделлю користувача, налаштовано middleware для перевірки токена й ролі користувача, а також реалізовано логіку оновлення профілю, зміни пароля, logout і refresh token.

Отже, лабораторна робота дозволила закріпити практичні навички побудови безпечного REST API, організації доступу до ресурсів і реалізації базових механізмів автентифікації та авторизації в сучасному вебзастосунку.