Вебзастосунок для обміну інформацією та організації роботи студента

ДОННЕР, Сергій
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7283
Title:	Вебзастосунок для обміну інформацією та організації роботи студента
Authors:	ТАЗЕТДІНОВ, Валерій ДОННЕР, Сергій
Keywords:	ВЕБЗАСТОСУНОК;НАВЧАЛЬНИЙ ПРОЦЕС;ІНФОРМАЦІЙНА ПЛАТФОРМА;ОРГАНІЗАЦІЯ РОБОТИ СТУДЕНТІВ;FASTAPI;PYTHON;POSTGRESQL;RESTFULAPI;БЕЗПЕКА ВЕБ-ДОДАТКІВ
Issue Date:	2025
Abstract:	Метою виконання даної кваліфікаційної роботи на здобуття освітнього ступеня «бакалавр» є розробка вебзастосунку для обміну інформацією та організації роботи студента, який забезпечить ефективний обмін інформацією та доступ до матеріалів навчання та завдань. Загальний обсяг роботи становить 104 сторінок. У роботі 9 рисунків, 1 таблиця. Для виконання роботи використано 20 літературних джерел та інтернет-ресурсів. Головне завдання полягає в розробці веб-простору для комунікації та доступу до навчальних ресурсів. Крім того, важливим завданням є забезпечення безпеки даних при взаємодії з вебзастосунком та реалізація надійної системи авторизації доступу до ресурсу для викладачів та адміністраторів. Стислий опис розділів кваліфікаційної роботи бакалавра складається з аналізу предметної області та постановки задачі; вибору засобів реалізації; проектування веб-додатку, бази даних та реалізація механізмів захисту.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7283
Appears in Collections:	123 Комп’ютерна інженерія (Комп'ютерні системи та мережі)
Files in This Item:
File	Description	Size	Format
1_ТИТУЛКА_Доннер-merged.pdf Restricted Access		3.35 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему:«Вебзастосунок для обміну інформацією
та організації роботи студента»
ЧДТУ.252179.003 ПЗ
Виконав: студент 4 курсу, групи КМ-2105
спеціальності 123 – «Комп’ютерна інженерія»
за освітньою програмою – «Комп’ютерні системи
та мережі»
Сергій ДОННЕР
Керівник
к.т.н., доцент
Валерій ТАЗЕТДІНОВ
Рецензент
к.т.н., доцент
Марія ЗАХАРОВА
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор ___________ Віра БАБЕНКО
Черкаси 2025 року
Форма № Н-9.01
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет: інформаційних технологій і систем
Кафедра: інформаційної безпеки та комп’ютерної інженерії
Освітньо-кваліфікаційний рівень: Бакалавр
Спеціальність 123 – Комп’ютерна інженерія
Освітня програма Комп’ютерні системи та мережі
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор _____________ Віра БАБЕНКО
«28» лютого 2025 року
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Доннер Сергію Андрійовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи: Вебзастосунок для обміну інформацією та організації роботи студента
Керівник роботи: к.т.н., доцент Тазетдінов Валерій Абударович
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «25» лютого 2025 р. № 53/03-03
2. Строк подання студентом роботи:
3. Вихідні дані до роботи:
Проблема: Фрагментація цифрових інструментів в освітньому процесі українських ЗВО.
Основні вимоги: Автентифікація, ролі, розклад, публікації, навчальні активності (матеріали, завдання,
здачі), комунікація.
Тип продукту: Клієнт-серверний вебзастосунок з RESTful API та базовим UI.
Засоби розробки: VS Code, Git, ОС Windows
Технологічний напрямок: Сучасні веб-технології, реляційна СКБД, мови з розвиненою екосистемою.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
1. Огляд предметної області та постановка задач
2. Аналіз та вибір засобів реалізації
3. Проектування вебзастосунку
4. Забезпечення безпеки вебзастосунку
5. Використання та тестування вебзастосунку
Висновки. Додатки. Список використаних джерел.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
1. Специфікація
2. Текст програми
3. Опис бази даних
4. Інструкція системного програміста
5. Інструкція користувача
6. Консультанти розділів роботи:
Розділ Прізвище, ініціали Підпис, дата
консультанта завдання видав завдання прийняв
7. Дата видачі завдання: 28 лютого 2025 року
КАЛЕНДАРНИЙ ПЛАН
Термін
№ з/п Назва етапів роботи виконання Примітка
етапів роботи
1 Аналіз предметної області, постановка задачі 03.03 – 14.03 виконано
2 Вибір та обґрунтування технологій 15.03 – 21.03 виконано
3 Проектування архітектури та бази даних 22.03 – 28.03 виконано
4 Розробка модуля автентифікації та 29.03 – 01.04 виконано
користувачів
5 Розробка модулів груп та предметів 02.04 – 05.04 виконано
6 Розробка модуля розкладу 06.04 – 11.04 виконано
7 Розробка модуля публікацій 12.04 – 18.04 виконано
8 Розробка базового інтерфейсу та API інтеграції 18.04 – 25.04 виконано
9 Розробка модуля завдань та дедлайнів 25.04 – 04.05 виконано
9 Тестування та налагодження 04.05 – 17.05 виконано
10 Написання пояснювальної записки 04.05 – 25.05 виконано
11 Підготовка презентаційних матеріалів 25.05 – 29.05 виконано
12 Попередній захист роботи 06.05 виконано
Студент ___________________________ Сергій ДОННЕР
(підпис)
Керівник роботи ___________________________ Валерій ТАЗЕТДІНОВ
(підпис)
АНОТАЦІЯ
Метою виконання даної кваліфікаційної роботи на здобуття освітнього
ступеня «бакалавр» є розробка вебзастосунку для обміну інформацією та
організації роботи студента, який забезпечить ефективний обмін інформацією
та доступ до матеріалів навчання та завдань.
Загальний обсяг роботи становить 104 сторінок. У роботі 9 рисунків,
1 таблиця. Для виконання роботи використано 20 літературних джерел та
інтернет-ресурсів.
Головне завдання полягає в розробці веб-простору для комунікації та
доступу до навчальних ресурсів. Крім того, важливим завданням є забезпечення
безпеки даних при взаємодії з вебзастосунком та реалізація надійної системи
авторизації доступу до ресурсу для викладачів та адміністраторів.
Стислий опис розділів кваліфікаційної роботи бакалавра складається з
аналізу предметної області та постановки задачі; вибору засобів реалізації;
проектування веб-додатку, бази даних та реалізація механізмів захисту.
Ключові слова:ВЕБЗАСТОСУНОК, НАВЧАЛЬНИЙ ПРОЦЕС,
ІНФОРМАЦІЙНА ПЛАТФОРМА, ОРГАНІЗАЦІЯ РОБОТИ СТУДЕНТІВ,
FASTAPI, PYTHON, POSTGRESQL, RESTFULAPI, БЕЗПЕКА ВЕБ-ДОДАТКІВ
ANNOTATION
The purpose of this qualification work for the degree of "Bachelor" is to
develop a web application for information exchange and organization of student
work, which will ensure effective information exchange and access to learning
materials and assignments.
The total volume of the work is 104 pages. The work contains 9 figures and 1
table. 20 literary sources and internet resources were used to perform the work.
The main task is to develop a web space for communication and access to
educational resources. In addition, an important task is to ensure data security when
interacting with the web application and to implement a reliable system for
authorizing access to the resource for lecturers and administrators.
A brief description of the sections of the bachelor's qualification work consists
of an analysis of the subject area and problem statement; selection of implementation
tools; design of the web application, database, and implementation of security
mechanisms.
Keywords: WEB APPLICATION, EDUCATIONAL PROCESS,
INFORMATION PLATFORM, STUDENT WORK ORGANIZATION, FASTAPI,
PYTHON, POSTGRESQL, RESTFUL API, WEB APPLICATION SECURITY
ЗМІСТ
ВСТУП......................................................................................................................4
1 ОГЛЯДПРЕДМЕТНОЇ ОБЛАСТІ ТАПОСТАНОВКА ЗАДАЧ……………..6
1.1 Актуальність проблеми організації навчального процесу...................6
1.2 Аналіз існуючих рішень та їх недоліки..................................................7
1.3Мета та задачі кваліфікаційної роботи...................................................8
2 АНАЛІЗ ТАВИБІР ЗАСОБІВ РЕАЛІЗАЦІЇ.....................................................12
2.1 Огляд сучасних технологій для веб-розробки.....................................12
2.2 Обґрунтування вибору мови програмування та фреймворку………12
2.3 Обґрунтування вибору системи керування базами даних
(PostgreSQL)……………………………………………………………….14
2.4 Обґрунтування вибору підходу до автентифікації (JWT)...................15
2.5 Вибір інструментів для міграцій бази даних (Alembic)......................15
2.6 Висновки до розділу..............................................................................16
3 ПРОЄКТУВАННЯВЕБ-ДОДАТКУ "STUDHUBUA"……............................18
3.1 Архітектура системи..............................................................................18
3.2 Проєктування бази даних......................................................................22
3.2.1 Опис основних сутностей.........................................................22
3.2.2 Схема бази даних (ER-діаграма)..............................................25
3.3 Проєктування API..................................................................................27
3.3.1 Принципи RESTful API............................................................27
3.3.2 Структура API ендпоінтів........................................................28
3.3.3 Схеми валідації даних (Pydantic).............................................28
3.4 Проєктування інтерфейсу користувача................................................31
3.5 Висновки до розділу..............................................................................34
ЧДТУ.252179.003 ПЗ
Змн. Арк. № докум. Підпис Дата
РозрКобив Доннер С.А. Вебзастосунок для обміну Літ. Лист Листів
Керівник Тазетдінов В.А.
а інформацією та організації 2 104
Рецензент Захарова М.В. роботи студента
Н.Контроль Гресько С.О. Кафедра ІБ та КІ
ф Пояснювальна записка
Затвердив Бабенко В.Г. гр. КМ-2105
е
д
р
а
К
К
-
0
6
4 ЗАБЕЗПЕЧЕННЯ БЕЗПЕКИ ВЕБ-ЗАСТОСУНКУ.........................................36
4.1 Загальні принципи безпеки веб-додатків та ідентифікація загроз.....36
4.2 Захист від міжсайтового скриптингу (XSS).........................................38
4.3 Захист від SQL-ін’єкцій.........................................................................41
4.4 Безпека автентифікації та авторизації..................................................44
4.4.1 Автентифікація користувачів за допомогою JWT..……........44
4.4.2 Авторизація на основі ролей....................................................46
4.4.3 Подальші можливі покращення безпеки
автентифікації/авторизації…………………………………………47
4.5 Захист від підробки міжсайтових запитів (CSRF)...............................47
4.6 Безпека завантаження та обробки файлів............................................50
4.7 Використання HTTPS............................................................................52
4.8 Висновки до розділу..............................................................................54
5 ВИКОРИСТАННЯТАТЕСТУВАННЯДОДАТКУ........................................57
5.1 Розгортання та запуск............................................................................57
5.2 Приклади використання API.................................................................57
5.3 Опис основних сценаріїв роботи користувачів...................................58
5.4 Підходи до тестування...........................................................................60
5.5 Висновки до розділу..............................................................................61
ВИСНОВКИ...........................................................................................................62
ДОДАТКИ:
А – 482.ЧДТУ.52179-01 Вебзастосунок для обміну інформацією та
організації роботи студента
СПИСОКВИКОРИСТАНИХДЖЕРЕЛ............................................................103
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 3
ВСТУП
Сучасний освітній процес у закладах вищої освіти України стрімко
трансформується під впливом цифрових технологій. Проте, незважаючи на
загальну тенденцію цифровізації, українські ЗВО часто стикаються з
проблемою інформаційної фрагментації, коли різні аспекти навчального
процесу обслуговуються різними системами. Студенти та викладачі щодня
змушені перемикатися між системами управління навчанням (LMS),
месенджерами, хмарними сховищами, електронною поштою та офіційними
веб-сайтами, витрачаючи дорогоцінний час на пошук актуальної інформації
та налагодження комунікації.
Практика показує, що такий розрізнений підхід має суттєві недоліки:
інформація дублюється або губиться, важливі оголошення проходять повз
адресатів, навчальний контент розпорошується по різних платформах, а
процес комунікації стає неефективним. Особливо гостро відчувається
відсутність єдиної системи відстеження завдань і дедлайнів, що негативно
впливає на якість навчального процесу та збільшує стрес серед студентів.
Існуючі LMS, як Moodle або Google Classroom, переважно зосереджені
на навчальних матеріалах і завданнях, залишаючи поза увагою інші аспекти
освітнього процесу. Месенджери, такі як Telegram чи Viber, стали фактичним
стандартом групової комунікації, але погано підходять для структурованого
зберігання інформації. Офіційні університетські портали часто мають
застарілий інтерфейс і обмежену функціональність, що не відповідає сучасним
запитам молоді.
Враховуючи ці виклики, та керуючись чинними нормативними
документами, що регламентують організацію навчального процесу та
контроль якості освіти [1, 2], я ініціював розробку. Проєкт створено з
урахуванням специфіки вітчизняної системи вищої освіти, вимог до
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 4
підсумкової атестації [3], та орієнтацією на сучасні технологічні стандарти
веб-розробки.Метою даної кваліфікаційної роботи є розробка програмного
забезпечення (серверна частина та базовий веб-інтерфейс) для єдиної
університетської платформи "StudHub UA", призначеної для обміну
інформацією, організації роботи студентів і викладачів.
В рамках роботи я самостійно реалізував весь комплекс робіт з
проектування та розробки системи: від аналізу предметної області, вибору
технологічного стеку та проектування архітектури до впровадження всіх
компонентів і тестування кінцевого продукту. На відміну від більшості
навчальних проєктів, розроблена система має потенціал для реального
впровадження в освітніх закладах після відповідної адаптації та інтеграції з
існуючими університетськими системами.
Платформа "StudHub UA" створюється як відкрите, масштабоване
рішення, з можливістю подальшого розширення функціоналу та адаптації до
потреб конкретних навчальних закладів. У перспективі планується розробка
мобільних додатків (iOS/Android), інтеграція з електронними системами
університетів та впровадження додаткових модулів для управління проєктами,
дедлайнами та публічними сторінками користувачів.
Дана пояснювальна записка до кваліфікаційної роботи структурована та
оформлена згідно з вимогами ДСТУ 3008:2015 [4], а бібліографічний опис та
скорочення виконані відповідно до стандартів ДСТУ 3582:2013 [5] та ДСТУ
ГОСТ 7.1:2006 [6].
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 5
1 ОГЛЯД ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ
1.1 Актуальність проблеми організації навчального процесу
Протягом останніх років процес цифровізації в закладах вищої освіти
України значно прискорився, особливо під впливом пандемії COVID-19 та
необхідності забезпечення дистанційного навчання. Проте трансформація
відбувалася часто хаотично, з використанням розрізнених інструментів, що
були доступні і зручні в той момент. Це призвело до формування складної
екосистеми цифрових рішень, яка потребує систематизації.
У ході дослідження поточного стану організації навчального процесу в
українських університетах, я виявив наступні ключові проблеми:
1. Множинність платформ і каналів комунікації (рисунок 1.1)
Рисунок 1.1 – Інформаційна фрагментація
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 6
2. Негативні наслідки інформаційної фрагментації:
– Значні витрати часу на пошук актуальної інформації на різних
платформах
– Висока ймовірність пропуску важливих повідомлень через
розпорошеність комунікації
– Відсутність єдиної системи для відстеження виконання завдань і
дедлайнів
– Неефективність комунікації через необхідність дублювання
повідомлень у різних каналах
3. Проблеми використання існуючих рішень:
– Стандартні LMS-системи не враховують специфіку організації
навчання в українських ЗВО
– Більшість рішень не інтегровані між собою, що вимагає ручного
перенесення даних
– Студентам та викладачам доводиться підтримувати множину
акаунтів на різних платформах
Проведений аналіз підтверджує актуальність створення єдиної
платформи, яка об'єднає всі необхідні інструменти для організації навчального
процесу в зручному та інтуїтивно зрозумілому інтерфейсі. Особливо
важливим є забезпечення мобільного доступу до інформації, враховуючи, що
смартфони стали основним інструментом комунікації для сучасних студентів.
1.2 Аналіз існуючих рішень та їх недоліки
Для розуміння вимог до нової системи та можливих підходів до її
реалізації я провів детальний аналіз існуючих рішень, що використовуються
в освітньому процесі. Основну увагу було приділено системам, які найбільш
поширені в українських закладах вищої освіти (таблиця 1.2).
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 7
Таблиця 1.2 – Переваги та недоліки існуючих рішень
Платформа/Інструмент Переваги (➕) Недоліки (➖)
• Потужне керування • Обмежена гнучкість розкладу
курсами • Незручна комунікація
LMS (Moodle, Teams) • Можливості оцінювання • Складний/перевантажений UI
• Інструменти для онлайн- • Слабка інтеграція з іншими
занять (Teams) системами ЗВО
• Менш гнучкий, ніж Moodle
• Простий інтерфейс
• Обмежена кастомізація
LMS (Google • Інтеграція з Google
• Залежність від Google
Classroom) Workspace
• Менше підходить для складних
• Швидке налаштування
структур
• Дуже зручні для швидкої • Неструктуроване зберігання
комунікації • Складність пошуку інформації
Месенджери (Telegram) • Висока залученість • Немає відстеження завдань
• Легкість створення • Змішування особистого та
груп/каналів освітнього
• Часто застарілий дизайн/UI
• Потенційна інтеграція з
• Обмежена функціональність
Внутрішні портали даними ЗВО
• Відсутність/слабкість мобільних
ЗВО • Орієнтація на потреби
версій
закладу
• Фокус на адмін. процесах
1.3 Мета та задачі кваліфікаційної роботи
Мета роботи полягає у розробці програмного забезпечення (серверна
частина та базовий веб-інтерфейс) для єдиної університетської платформи
"StudHub UA", призначеної для обміну інформацією та організації роботи
студентів і викладачів.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 8
Для досягнення поставленої мети я визначив наступні задачі:
1. Провести аналіз предметної області, виявити основні проблеми існуючої
організації навчального процесу та комунікації в університетах.
2. Проаналізувати існуючі програмні рішення, виявити їх переваги та
недоліки, обґрунтувати необхідність розробки нової інтегрованої
платформи.
3. Обґрунтувати вибір технологічного стеку для реалізації проєкту.
4. Розробити архітектуру веб-додатку.
5. Спроектувати структуру бази даних для зберігання інформації про
користувачів, групи, предмети, розклад, публікації та інші необхідні
сутності.
6. Реалізувати функціонал автентифікації та авторизації користувачів з
різними ролями (студент, викладач, адміністратор).
7. Реалізувати основні CRUD-операції.
8. Реалізувати функціонал перегляду розкладу за різними критеріями (дата,
група, викладач).
9. Реалізувати базовий функціонал стрічки публікацій з можливістю
створення, перегляду, коментування та оцінювання постів.
10.Реалізувати модуль керування навчальними матеріалами, що дозволяє
викладачам додавати, редагувати та видаляти матеріали (текст, файли) до
конкретних занять у розкладі, а студентам – переглядати та завантажувати
ці матеріали.
11.Розробити функціонал для створення та управління завданнями,
прив'язаними до занять у розкладі, включаючи встановлення назви, опису,
термінів виконання (дедлайнів) та максимальної оцінки.
12.Впровадити механізм здачі виконаних завдань студентами, з можливістю
надсилання текстової відповіді та прикріплення файлів.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 9
13.Створити систему оцінювання зданих робіт викладачами, що включає
встановлення оцінки, статусу роботи (наприклад, "Перевірено", "Потребує
доопрацювання") та надання текстового коментаря-фідбеку.
14.Реалізувати систему коментування для зданих робіт, забезпечуючи
можливість діалогу між студентом та викладачем стосовно конкретної
здачі.
15.Проаналізувати потенційні загрози безпеці веб-застосунку та впровадити
відповідні заходи захисту, зокрема від XSS-атак та несанкціонованого
доступу.
16.Створити базовий веб-інтерфейс для демонстрації основних можливостей
платформи.
17.Описати процес розробки, ключові технічні рішення та сценарії
використання додатку.
18.Спроектувати систему з розрахунком на подальше розширення
функціоналу, зокрема, поглиблення модуля управління завданнями
(наприклад, налаштування типів завдань, індивідуальні завдання),
розробку модуля для організації спільних студентських проєктів,
створення публічних сторінок користувачів (портфоліо), а також
забезпечення інтеграції з мобільними платформами (iOS/Android) через
розроблене API
Виконання поставлених задач спрямоване на створення кваліфікаційної
роботи, що відповідає вимогам до організації навчального процесу та
підготовки здобувачів [1], а також критеріям оцінювання [2, 3].
Практична цінність роботи полягає у створенні функціонального
прототипу системи, який після відповідної адаптації може бути впроваджений
у реальних освітніх закладах. Система забезпечує автоматизацію та
оптимізацію процесів комунікації між студентами та викладачами, значно
спрощує доступ до навчальних матеріалів, розкладу та оголошень.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 10
Впровадження модулів завдань, їх здачі та оцінювання, а також
навчальних матеріалів, безпосередньо інтегрованих з розкладом, дозволяє
створити цілісне навчальне середовище, зменшити навантаження на
викладачів щодо адміністрування та надати студентам чіткий інструмент для
відстеження навчального прогресу та взаємодії з викладачем. Система
коментування зданих робіт сприяє покращенню якості зворотного зв'язку та
ефективнішому засвоєнню матеріалу.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 11
2 АНАЛІЗ ТА ВИБІР ЗАСОБІВ РЕАЛІЗАЦІЇ
2.1 Огляд сучасних технологій для веб-розробки
Проведений мною аналіз сучасного ринку технологій для веб-розробки
дозволив систематизувати основні інструменти. Серверна частина (backend) є
фундаментом додатку, що забезпечує всю логіку обробки даних та відповідає
за взаємодію з базою даних. Дослідивши різноманітні технологічні стеки, я
виділив найбільш релевантні для поставлених завдань:
На рівні backend найбільш конкурентоспроможними рішеннями
виявилися Python з фреймворками Django, Flask[14] та FastAPI, Node.js з
Express та NestJS, PHP з Laravel та Ruby on Rails. Кожне з цих рішень має
власні переваги та обмеження, які я враховував при виборі, зважаючи на
специфіку проекту.
Для клієнтської частини (frontend) розглядалися як комплексні
JavaScript-фреймворки (React, Angular, Vue.js), так і більш традиційні підходи
з використанням HTML/CSS/JavaScript. Враховуючи потенційну необхідність
інтеграції з мобільними платформами, особливу увагу я приділив
можливостям створення адаптивних інтерфейсів та API для крос-
платформенної взаємодії.
Щодо систем управління базами даних, я проаналізував як реляційні
(PostgreSQL, MySQL, SQLite), так і нереляційні (MongoDB, Redis) варіанти.
Основний акцент при аналізі робився на надійність зберігання даних,
продуктивність при різних сценаріях навантаження та можливості
масштабування.
2.2 Обґрунтування вибору мови програмування (Python) та
фреймворку (FastAPI)
При виборі основної мови програмування для реалізації серверної
частини платформи я керувався необхідністю поєднання швидкості розробки
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 12
з високою продуктивністю кінцевого рішення. Python[13] був обраний як
оптимальний варіант після ретельного аналізу кількох ключових факторів:
1. Синтаксис та продуктивність розробки — чітка структура коду та
висока читабельність Python дозволили мені значно скоротити час
розробки та спростити подальшу підтримку проекту.
2. Екосистема бібліотек— наявність широкого спектру інструментів для
роботи з даними, автентифікацією, валідацією форм та інтеграцією з
різними сервісами дала можливість ефективно вирішувати комплексні
задачі без необхідності "винаходити велосипед".
3. Гнучкість інтеграцій — Python забезпечує простоту інтеграції з
іншими системами, що є критичним для проекту, який має потенціал
для впровадження в існуючу ІТ-інфраструктуру університетів.
Серед Python-фреймворків я зупинив свій вибір на FastAPI з таких
причин (рис. 2.1).
Рисунок 2.1 – Переваги FastAPI
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 13
Практичний досвід розробки з FastAPI підтвердив правильність цього
вибору, дозволивши швидко створити прототип системи з можливістю
подальшого нарощування функціоналу[7].
2.3 Обґрунтування вибору системи керування базами даних
(PostgreSQL)
Вибір PostgreSQL як системи керування базою даних був зумовлений
необхідністю забезпечити надійне зберігання структурованих даних
університетської платформи з урахуванням потенційного масштабування. Мій
аналіз показав, що PostgreSQL має ряд переваг (рис. 2.2), які роблять його
оптимальним для проекту "StudHub"[11].
Рисунок 2.2 – переваги PostgreSQL
Це рішення і надало у ході розробки можливість створення
оптимізованої БД.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 14
2.4 Обґрунтування вибору підходу до автентифікації (JWT)
Реалізація надійної системи автентифікації та авторизації користувачів
була одним із ключових завдань проекту. Після аналізу різних підходів я
вирішив використати механізм JSON Web Tokens (JWT) з наступних
причин[16]:
1. Безсерверна архітектура (Stateless) — JWT не вимагає зберігання
стану сесії на сервері.
2. Безпека та захист даних— впроваджена мною схема з використанням
пари токенів (короткоживучий access token та довгоживучий refresh
token) забезпечує баланс між безпекою та зручністю користування. Для
підвищення захисту я реалізував механізм ротації refresh токенів та
обмеження їх дії за IP-адресою.
3. Універсальність для різних клієнтів — JWT-токени легко
передаються в HTTP-заголовках, що спростило б інтеграцію з різними
типами клієнтів: веб-браузерами, мобільними додатками та зовнішніми
сервісами, забезпечуючи єдиний підхід до автентифікації.
4. Продуктивність — відсутність необхідності звертатися до бази даних
при кожному запиті для перевірки сесії значно підвищує швидкодію
API.
В ході імплементації я особливу увагу приділив захисту від поширених
вразливостей, пов'язаних з JWT, включаючи правильне зберігання секретів,
валідацію всіх полів токену та використання HTTPS для передачі даних.
2.5 Вибір інструментів для міграцій бази даних (Alembic)
Для ефективного управління еволюцією схеми бази даних я обрав
фреймворк Alembic, який є стандартним інструментом міграцій для
SQLAlchemy[8,9]. Цей вибір ґрунтувався на таких факторах:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 15
1. Тісна інтеграція з SQLAlchemy — Alembic безпосередньо працює з
моделями SQLAlchemy, що дозволило мені автоматично генерувати
міграції на основі змін у моделях даних.
2. Контроль версій схеми — реалізована система міграцій забезпечує
чітке відстеження всіх змін схеми бази даних з можливістю як оновлення
до останньої версії, так і відкату до попередніх станів, що надзвичайно
важливо при розгортанні оновлень.
3. Автоматизація процесів — я налаштував автоматичну генерацію
міграцій на основі моделей даних з можливістю їх ручного коригування,
що дозволило знайти оптимальний баланс між швидкістю розробки та
контролем над змінами.
4. Гнучкість при розгортанні — створений мною процес міграцій
дозволяє безпроблемно розгортати додаток у різних середовищах
(розробка, тестування, продакшн) з мінімальними ручними
втручаннями.
5. Документованість змін— кожна міграція містить опис внесених змін,
що значно спрощує відстеження еволюції бази даних та допомагає в
діагностиці потенційних проблем.
У процесі розробки я створив систему міграцій, яка не лише забезпечує
управління структурою бази даних, але й містить скрипти для початкового
наповнення системи базовими даними (наприклад для груп), що спрощує
розгортання нових інстансів додатку.
2.6 Висновки до розділу
Проведений мною аналіз та вибір технологічного стеку для реалізації
платформи "StudHub UA" базувалися на необхідності створення
масштабованого, надійного та функціонального рішення, з урахуванням
можливості його подальшої інтеграції з існуючими системами університетів.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 16
Обраний стек технологій (Python, FastAPI, PostgreSQL, SQLAlchemy,
Alembic, JWT) дозволив досягти оптимального балансу між швидкістю
розробки, продуктивністю та підтримуваністю системи. Асинхронна природа
FastAPI в поєднанні з надійністю PostgreSQL забезпечили високу швидкодію.
Особливу увагу я приділив масштабованості рішення — спроектована
архітектура дозволяє як нарощувати функціональність (нові модулі для
завдань, дедлайнів, проектів), так і збільшувати кількість користувачів
системи без суттєвої переробки коду.
Система автентифікації на основі JWT забезпечує необхідний рівень
безпеки при збереженні зручності використання для кінцевих користувачів
різних типів (студенти, викладачі, адміністратори). Розроблене рішення також
враховує необхідність інтеграції з мобільними клієнтами через REST API.
Впроваджений підхід до управління міграціями баз даних з
використанням Alembic створює надійну основу для подальшої еволюції
схеми даних з мінімальними ризиками втрати цілісності при оновленнях.
Таким чином, обраний технологічний стек повністю відповідає
поставленим задачам і створює надійну основу для розробки повноцінної
університетської платформи з подальшою можливістю її інтеграції з
існуючими системами вищих навчальних закладів.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 17
3 ПРОЕКТУВАННЯ ВЕБ-ДОДАТКУ "STUDHUB UA"
3.1 Архітектура системи
У процесі проєктування веб-додатку "StudHub UA" я спирався на сучасні
підходи до розробки масштабованих веб-систем. Основою архітектури стала
клієнт-серверна модель із RESTful API[15], що забезпечує універсальний
інтерфейс взаємодії між компонентами системи та гнучкість у подальшому
розширенні функціоналу.
Розроблена архітектура складається з наступних основних компонентів:
Клієнтські додатки (Frontend):
 Веб-інтерфейс – реалізований за допомогою HTML, CSS та JavaScript.
Основною особливістю розробленого інтерфейсу є можливість
безпечного відображення контенту, створеного користувачами завдяки
інтеграції бібліотек Showdown[18] (для перетворення Markdown у
HTML) та DOMPurify[19] (для санітизації HTML-вмісту). Шаблонізація
здійснюється на стороні сервера з використанням вбудованого в FastAPI
механізму Jinja2Templates для базових сторінок, у той час як динамічна
взаємодія забезпечується JavaScript та API-запитами.
 Мобільні додатки (iOS/Android) – на етапі проєктування я передбачив
можливість майбутньої інтеграції мобільних клієнтів, які зможуть
використовувати той самий API, що й веб-інтерфейс.
Серверна частина (Backend):
 Веб-сервер (ASGI) – у якості сервера обрано Uvicorn, який забезпечує
асинхронну обробку запитів та високу продуктивність при запуску
FastAPI-додатків.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 18
 Веб-фреймворк – основою backend-частини став FastAPI[7], який
відповідає за обробку HTTP-запитів, маршрутизацію, валідацію даних
та формування відповідей. Важливою перевагою FastAPI є автоматична
генерація документації API, що спрощує інтеграцію з іншими
системами.
 Сервісний шар – я розробив окремі модулі (розміщені в каталозі
app/services), які інкапсулюють логіку системи: створення користувачів,
управління розкладом, перевірка прав доступу тощо.
 Шар доступу до даних (ORM) – для взаємодії з базою даних
використано SQLAlchemy, що дозволяє працювати з даними через
об'єктні моделі Python[8], абстрагуючись від деталей SQL-запитів.
 База даних – для зберігання даних обрано PostgreSQL як надійну,
продуктивну та розширювану СКБД з підтримкою складних запитів та
транзакцій.
 Інструмент міграцій – для керування змінами схеми бази даних
інтегровано Alembic, що дозволяє контролювати версіонування
структури БД[9] та спрощує процес оновлення додатку.
Взаємодія між компонентами системи відбувається за наступною
схемою:
1. Клієнт (веб-браузер або потенційно мобільний додаток) надсилає HTTP-
запит (GET, POST, PATCH, DELETE) до відповідного ендпоінту API на
сервері.
2. Uvicorn приймає запит та передає його до FastAPI-додатку.
3. FastAPI визначає відповідний обробник запиту на основі URL та HTTP-
методу.
4. За допомогою Pydantic відбувається валідація вхідних даних[10] (якщо
такі є).
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 19
5. Обробник запиту викликає необхідні функції сервісного шару для
виконання бізнес-логіки.
6. Сервісний шар взаємодіє з базою даних через SQLAlchemy.
7. SQLAlchemy генерує оптимізовані SQL-запити до PostgreSQL.
8. PostgreSQL виконує запити та повертає результати.
9. SQLAlchemy перетворює отримані дані з реляційної форми на об'єкти
Python.
10.Сервісний шар обробляє дані відповідно до бізнес-логіки та повертає
результат обробнику запиту.
11.FastAPI серіалізує результат у JSON-відповідь за допомогою
Pydantic[10].
12.Клієнт отримує HTTP-відповідь і відображає результат користувачу.
Розроблена архітектура (Рисунок 3.1) забезпечує високу модульність
системи, що дозволяє незалежно розвивати її компоненти, а також
горизонтальне масштабування для обробки зростаючого навантаження.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 20
Рисунок 3.1 – Архітектура веб-додатку
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 21
3.2 Проектування бази даних
3.2.1 Опис основних сутностей
Аналіз предметної області та вимог до системи дозволив мені виділити
наступні основні сутності та спроєктувати відповідні таблиці бази даних:
1. User (users) – представляє користувачів системи різних типів (студенти,
викладачі, адміністратори). Дана сутність має зв'язки з:
o Group (через групу для студентів та через асоціативну таблицю
для викладачів)
o Subject (для викладачів, які ведуть предмети)
o Post (як автор публікацій)
o Comment (як автор коментарів)
o PostLike (для відстеження вподобань)
2. Group (groups) – представляє академічні групи. Пов'язана з:
o User (студенти групи та викладачі через асоціативну таблицю)
o Schedule (записи розкладу для групи)
3. Subject (subjects) – навчальні предмети/дисципліни. Має зв'язки з:
o User (викладачі, що ведуть предмет)
o Schedule (записи розкладу з цього предмету)
4. Schedule (schedules) – записи розкладу занять. Пов'язані з Group та
Subject. Для забезпечення цілісності даних впроваджено
UniqueConstraint, що запобігає дублюванню записів розкладу для однієї
групи в один час.
5. Post (posts) – публікації користувачів. Пов'язані з:
o User (автор)
o Comment (коментарі до публікації)
o PostLike (вподобання)
o PostAttachment (прикріплені файли)
6. Comment (comments) – коментарі до публікацій. Мають зв'язки з:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 22
o User (автор коментаря)
o Post (публікація, до якої належить коментар)
o Comment (батьківський коментар, для реалізації вкладених
відповідей)
7. PostLike (post_likes) – асоціативна таблиця для відстеження вподобань
публікацій. Пов'язує User та Post з UniqueConstraint для запобігання
дублюванню вподобань.
8. PostAttachment (post_attachments) – файли, прикріплені до публікацій.
Пов'язані з:
o Post (публікація)
o User (користувач, який завантажив файл)
9. teacher_group_association – асоціативна таблиця для зв'язку "багато-
до-багатьох" між викладачами (User) та групами (Group), які вони
викладають.
10. ScheduleMaterial (schedule_materials) – навчальні матеріали,
прикріплені викладачем до конкретного заняття в розкладі. Сутність
містить заголовок, опис матеріалу та посилання на завантажувача
(викладача). Пов'язана з:
o Schedule (заняття, до якого належить матеріал)
o User (викладач, який завантажив матеріал)
o ScheduleMaterialAttachment (вкладені файли до матеріалу)
11. ScheduleMaterialAttachment (schedule_material_attachments) – файли,
прикріплені до навчальних матеріалів заняття. Містить інформацію про
ім'я файлу, шлях до нього на сервері, розмір та тип. Пов'язана з:
o ScheduleMaterial (матеріал, до якого належить вкладення)
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 23
12.Assignment (assignments) – домашні завдання, що створюються
викладачем та прив'язуються до конкретного заняття в розкладі.
Сутність включає заголовок, опис завдання, дату здачі (дедлайн),
максимальну можливу оцінку. Кожне заняття в розкладі може мати
лише одне завдання (зв'язок один-до-одного з Schedule через унікальний
зовнішній ключ). Пов'язана з:
o Schedule (заняття, до якого належить завдання)
o AssignmentAttachment (файли, прикріплені викладачем до
завдання)
o Submission (здані роботи студентів по цьому завданню)
13.AssignmentAttachment (assignment_attachments) – файли, прикріплені
викладачем до умов завдання.Містить інформацію про ім'я файлу, шлях,
розмір, тип та користувача, що завантажив файл. Пов'язана з:
o Assignment (завдання, до якого належить вкладення)
o User (викладач, який завантажив файл)
14. Submission (submissions) – здані роботи студентів на конкретне
завдання. Сутність зберігає текстову відповідь студента, поточний
статус здачі (наприклад, "здано", "перевірено", "потребує
доопрацювання"), отриману оцінку та коментар викладача.
Забезпечується унікальність здачі для пари студент-завдання. Пов'язана
з:
– Assignment (завдання, на яке здається робота)
– User (студент, який здав роботу)
– SubmissionAttachment (файли, прикріплені студентом до своєї
здачі)
– SubmissionComment (коментарі-обговорення цієї здачі)
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 24
15. SubmissionAttachment (submission_attachments) – файли, прикріплені
студентом до своєї зданої роботи. Містить інформацію про ім'я файлу,
шлях, розмір та тип. Пов'язана з:
o Submission (здана робота, до якої належить вкладення)
16. SubmissionComment (submission_comments) – коментарі в рамках
обговорення конкретної зданої роботи між студентом та викладачем.
Містить текст коментаря та інформацію про автора. Пов'язана з:
o Submission (здана робота, яку обговорюють)
o User (автор коментаря – студент або викладач)
Додатково в базі даних присутня службова таблиця alembic_version, яка
використовується системою міграцій Alembic для відстеження поточної версії
схеми бази даних.
3.2.2 Схема бази даних (ER-діаграма)
На основі виділених сутностей та зв'язків між ними я розробив схему
бази даних (Рисунок 3.2), яка відображає структуру даних системи та всі
зв'язки між таблицями.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 25
Рисунок 3.2 – ER-діаграма
Розроблена схема бази даних забезпечує:
 Нормалізацію даних
 Цілісність даних
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 26
 Ефективність запитів
 Масштабованість для подальшого розширення функціоналу
Опис таблиць надано в додатку В.
3.3 Проектування API
3.3.1 Принципи RESTful API
При проєктуванні API для веб-додатку я дотримувався основних
принципів RESTful архітектури[15]:
1. Клієнт-сервер – чітке розділення відповідальності між клієнтом та
сервером. Клієнт відповідає за інтерфейс та взаємодію з користувачем,
сервер – за обробку запитів, бізнес-логіку та роботу з даними.
2. Stateless (без збереження стану) – кожен запит від клієнта містить всю
необхідну інформацію для його обробки. Сервер не зберігає стан клієнта
між запитами. Для ідентифікації користувачів використано JWT-токени,
що передаються з кожним запитом.
3. Кешування – відповіді сервера можуть бути позначені як такі, що
можуть кешуватися, для підвищення продуктивності та зменшення
навантаження.
4. Єдиний інтерфейс – стандартизований спосіб взаємодії, що включає:
– Використання HTTP-методів (GET, POST, PUT/PATCH, DELETE)
– Структуровані URL-шляхи, що ідентифікують ресурси
– Передача даних у форматі JSON
– HATEOAS (гіперпосилання, що пов'язують ресурси)[15]
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 27
Рисунок 3.3 – Основні принципи RESTful API
3.3.2 Структура API ендпоінтів
Розроблений API структуровано за групами ресурсів і розміщено під
базовим шляхом /api/v1/, що дозволяє в майбутньому впроваджувати нові
версії API без порушення сумісності.
Повна документація API з детальним описом усіх ендпоінтів, параметрів
запитів, форматів відповідей та кодів статусу доступна через вбудовані в
FastAPI інтерфейси Swagger UI (/docs) та ReDoc (/redoc). Приклади
специфікації наведено в Додатку А.
3.3.3 Схеми валідації даних (Pydantic)
Для забезпечення коректності даних, що передаються через API, їх
валідації та зручної серіалізації/десеріалізації, в проекті активно
використовується бібліотека Pydantic[10]. Усі схеми даних розміщені в
каталозі app/schemas/. Інтеграція Pydantic з FastAPI надає наступні ключові
переваги [7, 10]:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 28
1. Автоматична валідація даних: Вхідні дані для API ендпоінтів
автоматично перевіряються на відповідність визначеним типам та
обмеженням (наприклад, мінімальна/максимальна довжина рядка,
діапазон числових значень, валідність email тощо). У разі
невідповідності FastAPI автоматично повертає клієнту інформативну
помилку валідації (статус 422).
2. Перетворення типів даних: Pydantic забезпечує перетворення даних
між різними форматами, зокрема між JSON-об'єктами, що надходять у
запитах, та Python-об'єктами (екземплярами схем), з якими працює
бізнес-логіка додатку, і навпаки при формуванні відповіді.
3. Генерація документації API: Визначення схем Pydantic
використовується FastAPI для автоматичної генерації детальної схеми
OpenAPI [7], яка потім відображається в інтерактивних інтерфейсах
Swagger UI та ReDoc. Це включає опис моделей даних, їх полів, типів та
обмежень.
4. Узгодженість та надійність: Використання строго типізованих схем
гарантує узгодженість форматів даних на всіх рівнях системи,
зменшуючи ймовірність помилок, пов'язаних з невідповідністю типів
або структури даних.
Для кожного основного ресурсу системи розроблено набір Pydantic-схем.
Зокрема було розроблено та інтегровано схеми для нового функціоналу:
 Навчальні Матеріали до Занять (Schedule Material та Schedule
Material Attachment):
o Схеми для створення, оновлення та відображення матеріалів,
включаючи поля для заголовка, опису, посилання на заняття та
завантажувача.
o Схеми для вкладень до матеріалів, що описують метадані файлів
(filename, filesize, mimetype) та містять поле download_url для
отримання файлу.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 29
 Завдання до Занять (Assignment та AssignmentAttachment):
o Схеми для створення, оновлення та відображення завдань, що
включають поля для назви, опису, терміну виконання (due_date),
максимальної оцінки та зв'язку із заняттям.
o Схеми для вкладень до умов завдання (файли від викладача).
 Здані Роботи (Submission та SubmissionAttachment):
o Схеми для створення здачі студентом (SubmissionCreateStudent),
що включає текстову відповідь.
o Схеми для оновлення здачі студентом (SubmissionUpdateStudent).
o Схеми для оцінювання здачі викладачем
(SubmissionUpdateTeacher), що включають поля для оцінки,
коментаря викладача та статусу роботи.
o Схеми для відображення зданих робіт:
 SubmissionRead: детальна схема для однієї здачі, включаючи
всі поля, вкладення та коментарі.
 SubmissionReadForTeacher: схема для списку здач, яку
бачить викладач, з інформацією про студента, статус,
оцінку, контент та вкладення.
 SubmissionReadForStudent: схема для студента, щоб бачити
деталі своєї здачі.
o Схеми для вкладень до зданої роботи (SubmissionAttachmentRead).
 Коментарі до Зданих Робіт (SubmissionComment):
o Схеми для створення (SubmissionCommentCreate) та відображення
(SubmissionCommentRead) коментарів, що включають текст
коментаря, автора та час створення.
Також використовуються додаткові схеми для токенів автентифікації
(Token, TokenData) та адміністративних операцій.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 30
3.4 Проектування інтерфейсу користувача
Хоча основний фокус даної кваліфікаційної роботи зосереджено на
розробці серверної частини веб-додатку, для демонстрації ключових
функціональних можливостей системи було створено базовий веб-інтерфейс.
Цей інтерфейс реалізовано з використанням HTML-шаблонів, що
обробляються шаблонізатором Jinja2 на стороні сервера, каскадних таблиць
стилів (CSS) для візуального оформлення, та JavaScript для забезпечення
динамічної взаємодії з користувачем та асинхронної комунікації з
розробленим API.
Основні розроблені сторінки та функціональні блоки інтерфейсу
включають:
 Головна сторінка (/): Надає загальну інформацію про платформу
"StudHub UA" та пропонує навігацію до основних розділів, таких як
вхід, реєстрація або профіль (для вже автентифікованих користувачів).
 Сторінки автентифікації та реєстрації (/login, /register): Містять
форми для входу існуючих користувачів та реєстрації нових, з
валідацією введених даних на стороні клієнта та сервера.
 Сторінка профілю користувача (/profile): Персоналізована сторінка,
що відображає інформацію про поточного користувача. Вміст та
доступні дії на цій сторінці адаптуються залежно від ролі користувача:
o Для всіх користувачів: Можливість перегляду та оновлення
основних даних профілю (email, ім'я, прізвище).
o Для студентів: Відображення інформації про академічну групу
(якщо призначено), можливість вибору групи (якщо ще не
обрано), доступ до розкладу та стрічки публікацій.
o Для викладачів: Інструменти для керування власними
навчальними предметами (створення, редагування, видалення) та
управління списком груп, яким викладач проводить заняття.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 31
 Сторінка розкладу занять (/schedule): Дозволяє користувачам
переглядати розклад за обраний період часу з можливістю фільтрації за
академічною групою.
o Для викладачів та адміністраторів: Надається функціонал для
додавання нових занять, редагування та видалення існуючих
записів у розкладі через модальне вікно.
o Для студентів: Для занять їхньої групи відображається кнопка
"Деталі Пари", що веде на сторінку керування конкретним
заняттям.
 Сторінка керування заняттям (/schedule-entry/{id}/manage):
Динамічна сторінка, доступ до якої контролюється залежно від ролі
користувача та його приналежності до заняття. Надає деталізовану
інформацію про конкретне заняття та є центральним вузлом для
взаємодії з навчальними матеріалами та завданнями:
o Відображення інформації про заняття: Дата, час, предмет,
група, викладач, аудиторія.
o Секція "Матеріали до Заняття":
 Для викладачів/адмінів: Можливість додавати нові
матеріали (текстовий опис, прикріплені файли), редагувати
та видаляти існуючі матеріали та їх вкладення.
 Для студентів групи: Можливість перегляду опису
матеріалів та завантаження прикріплених файлів.
o Секція "Домашнє Завдання":
 Для викладачів/адмінів: Інтерфейс для створення нового
завдання до заняття (назва, опис, дедлайн, максимальна
оцінка, прикріплені файли), а також для редагування або
видалення існуючого завдання та його вкладень.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 32
 Для студентів групи: Відображення умов завдання,
включаючи опис та прикріплені викладачем файли.
o Секція "Ваша Здача" (для студентів): Якщо до заняття є
завдання, студент бачить форму для здачі роботи, що дозволяє
ввести текстову відповідь та прикріпити файли. Також
відображається статус поточної здачі, оцінка та коментар
викладача (якщо є). Передбачена можливість перездачі роботи,
якщо це дозволено статусом.
o Секція "Здані Роботи Студентів" (для викладачів/адмінів):
Відображає список робіт, зданих студентами групи на завдання по
поточному заняттю. Для кожної здачі показується інформація про
студента, час здачі, статус, текстова відповідь та прикріплені
файли. Викладач має можливість відкрити модальне вікно для
детального перегляду роботи, встановлення оцінки, зміни статусу
та надання коментаря-фідбеку.
o Секція "Обговорення роботи": Як для студента (під його
здачею), так і для викладача (в модальному вікні оцінювання)
реалізовано можливість перегляду історії коментарів та додавання
нових, забезпечуючи діалог стосовно конкретної зданої роботи.
 Стрічка публікацій (/posts, /posts/create, /posts/{id}): Надає
функціонал для створення текстових публікацій, їх перегляду,
коментування та оцінювання (лайки), аналогічно до соціальних
платформ.
 Адміністративна панель (/admin): Спеціалізований інтерфейс,
доступний лише користувачам з роллю адміністратора. Надає
інструменти для керування користувачами (перегляд, зміна ролей,
статусу активності, призначення груп) та академічними групами
(створення, редагування, видалення).
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 33
Особливу увагу при розробці інтерфейсу було приділено безпеці
відображення користувацького контенту. Текстовий вміст, що може вводитися
користувачами (наприклад, описи завдань, відповіді на завдання, коментарі,
вміст публікацій), обробляється на стороні клієнта для запобігання XSS-
атакам. Якщо передбачається форматування тексту за допомогою Markdown,
він спочатку конвертується в HTML бібліотекою Showdown, а потім
отриманий HTML санітизується за допомогою DOMPurify перед
відображенням в DOM. Для простого текстового виводу використовується
властивість textContent.
Для забезпечення динамічності та інтерактивності інтерфейсу широко
використовуються JavaScript та асинхронні запити до API за допомогою Fetch
API. Це дозволяє оновлювати частини сторінки без необхідності повного
перезавантаження, покращуючи загальний користувацький досвід.
Примітка: скріншоти ключових сторінок та елементів інтерфейсу, що
ілюструють описаний функціонал, наведено в Додатку Г.
3.5 Висновки до розділу
У цьому розділі я представив детальне проєктування веб-додатку "StudHub
UA", що включає:
1. Розробку масштабованої клієнт-серверної архітектури на основі
RESTful API, що забезпечує гнучкість та можливість подальшого
розширення системи, включаючи інтеграцію з мобільними
платформами.
2. Проєктування реляційної бази даних, що відображає сутності
предметної області та зв'язки між ними, з дотриманням принципів
нормалізації та забезпеченням цілісності даних.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 34
3. Розробку структурованого API з чіткою ієрархією ресурсів та
ендпоінтів, що слідує принципам REST, з використанням сучасних
механізмів валідації та серіалізації даних через Pydantic.
4. Створення базового веб-інтерфейсу для демонстрації можливостей
системи з фокусом на безпечну обробку користувацького контенту.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 35
4 ЗАБЕЗПЕЧЕННЯ БЕЗПЕКИ ВЕБ-ЗАСТОСУНКУ
4.1 Загальні принципи безпеки веб-додатків та ідентифікація загроз
Безпека є критично важливим аспектом будь-якого сучасного веб-
застосунку, особливо такого, що обробляє персональні дані користувачів та
забезпечує освітній процес, як платформа "StudHub UA". Недостатня увага до
питань безпеки може призвести до витоку конфіденційної інформації,
несанкціонованого доступу, порушення цілісності даних та репутаційних
втрат. Тому при розробці платформи "StudHub UA" значну увагу було
приділено ідентифікації потенційних загроз та впровадженню відповідних
механізмів захисту.
Розробка безпечного застосунку ґрунтується на кількох
фундаментальних принципах (рис. 4.1).
Рисунок 4.1 – Принципи безпеки веб-застосунку
У контексті веб-застосунку "StudHub UA" було ідентифіковано та
проаналізовано наступні поширені типи загроз, спираючись на класифікації,
такі як OWASP Top 10 [17]:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 36
 Міжсайтовий скриптинг (XSS – Cross-Site Scripting): Впровадження
зловмисного клієнтського коду (зазвичай JavaScript) на сторінки, що
переглядаються іншими користувачами. Це може призвести до крадіжки
сесійних даних, фішингу, дефейсу сайту.
 SQL-ін'єкції (SQL Injection): Впровадження шкідливих SQL-команд
через вхідні дані користувача, що може дозволити зловмиснику
отримати несанкціонований доступ до бази даних, модифікувати або
видалити дані.
 Проблеми з автентифікацією та управлінням сесіями: Слабкі паролі,
недостатній захист сесійних токенів, можливість підбору облікових
даних.
 Порушення контролю доступу (Broken Access Control): Недостатньо
суворі перевірки прав доступу, що дозволяють користувачам
виконувати дії або отримувати дані, на які вони не мають авторизації.
 Підробка міжсайтових запитів (CSRF – Cross-Site Request Forgery):
Примушення браузера автентифікованого користувача виконувати
небажані дії на сайті без його відома.
 Небезпечна десеріалізація: Обробка потенційно небезпечних
серіалізованих об'єктів, що може призвести до виконання довільного
коду.
 Використання компонентів з відомими вразливостями: Несвоєчасне
оновлення бібліотек та фреймворків.
 Недостатнє логування та моніторинг: Ускладнює виявлення атак та
розслідування інцидентів безпеки.
 Небезпечне завантаження файлів: Можливість завантаження файлів
зі шкідливим вмістом або виконання коду через завантажені файли.
 Розкриття чутливої інформації: Неналежне зберігання або передача
паролів, ключів API, персональних даних.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 37
У наступних підрозділах буде детально розглянуто, які конкретні заходи
були вжиті в рамках розробки "StudHub UA" для протидії цим та іншим
загрозам.
4.2 Захист від міжсайтового скриптингу (XSS)
Міжсайтовий скриптинг (Cross-Site Scripting, XSS) є однією з
найпоширеніших та найнебезпечніших вразливостей веб-застосунків. Атака
XSS полягає у впровадженні зловмисного клієнтського коду (зазвичай
JavaScript) на веб-сторінки, які переглядаються іншими користувачами. Якщо
застосунок не проводить належну санітизацію даних, введених користувачем,
перед їх відображенням, цей шкідливий код може виконатися в браузері
жертви, що може призвести до крадіжки сесійних cookie, перехоплення даних,
фішингу, зміни вмісту сторінки або перенаправлення на зловмисні сайти.
В рамках розробки платформи "StudHub UA" було впроваджено кілька
рівнів захисту для запобігання XSS-атакам, зокрема при обробці та
відображенні контенту, створеного користувачами (наприклад, описи завдань,
відповіді студентів на завдання, коментарі до зданих робіт, вміст публікацій
та коментарі до них).
Основні підходи до захисту від XSS в "StudHub UA":
1. Безпечне відображення простого тексту за допомогою textContent:
У випадках, коли очікується, що користувацький ввід є звичайним
текстом і не повинен містити жодного HTML-форматування, для його
відображення на веб-сторінці використовується властивість DOM-
елементів textContent замість innerHTML. При присвоєнні рядка
властивості textContent, браузер автоматично обробляє всі спеціальні
HTML-символи (такі як <, >, & тощо) як звичайний текст, а не як
частину HTML-розмітки. Це ефективно запобігає інтерпретації будь-
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 38
яких впроваджених тегів <script> або інших HTML-конструкцій як
виконуваного коду.
o Приклад застосування: Відображення імен користувачів, назв
груп, заголовків (якщо вони не підтримують форматування),
простих текстових полів у формах після їх заповнення (якщо вони
відображаються десь на сторінці без змін).
2. Обробка та санітизація форматованого контенту (Markdown):
Платформа "StudHub UA" дозволяє користувачам використовувати
Markdown для форматування тексту в певних полях, таких як вміст
публікацій, коментарі до публікацій, описи завдань та відповіді на
завдання. Для безпечного відображення такого контенту
використовується двоетапний підхід на стороні клієнта (в JavaScript):
o Етап 1: Конвертація Markdown в HTML за допомогою
Showdown.js. Бібліотека Showdown [18] використовується для
перетворення розмітки Markdown, введеної користувачем, у
відповідний HTML-код. На цьому етапі важливо налаштувати
Showdown таким чином, щоб він не генерував потенційно
небезпечні HTML-конструкції, якщо це можливо (наприклад,
через опції noHeaderId: true, simpleLineBreaks: true).
o Етап 2: Санітизація згенерованого HTML за допомогою
DOMPurify.js. Після перетворення Markdown на HTML,
отриманий HTML-рядок пропускається через бібліотеку
DOMPurify [19]. DOMPurify – це надійний санітайзер HTML, який
аналізує HTML-структуру та видаляє будь-які потенційно
небезпечні теги (наприклад, <script>, <style>, <iframe), атрибути
(наприклад, onerror, onload, onclick, style з небезпечними CSS-
властивостями) та інші конструкції, які можуть призвести до XSS.
У проекті використовується
конфігурація DOMPurify.sanitize(rawHtml, { USE_PROFILES:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 39
{ html: true } }), яка дозволяє безпечний набір HTML-тегів [19] та
атрибутів, типових для форматованого контенту (параграфи,
списки, виділення тексту, посилання, зображення, таблиці тощо),
але блокує виконання JavaScript.
Рисунок 4.2 – Процес безпечної обробки Markdown-контенту.
Ця функція використовується для відображення описів завдань,
відповідей студентів, коментарів до здач та іншого контенту, де дозволено
Markdown.
3. Валідація вхідних даних на стороні сервера:
Хоча основний захист від XSS при відображенні відбувається на клієнті,
FastAPI разом з Pydantic забезпечує валідацію типів даних на сервері[7,
10]. Для рядкових полів можна встановити обмеження на довжину
(max_length у схемах Pydantic), що опосередковано може ускладнити
впровадження дуже довгих шкідливих скриптів. Однак, це не є
основним механізмом захисту від XSS.
4. Content Security Policy (CSP) – як потенційне майбутнє
покращення[12]:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 40
На даному етапі розробки CSP не було впроваджено на рівні HTTP-
заголовків, але це є важливим напрямком для подальшого посилення
безпеки. Налаштування CSP дозволило б визначити довірені джерела
для скриптів, стилів та інших ресурсів, що значно обмежує можливості
виконання неавторизованого коду, навіть якщо XSS-вразливість була б
пропущена на етапі санітизації.
Завдяки комбінації використання textContent для простого тексту та
ретельної санітизації HTML, згенерованого з Markdown, за допомогою
DOMPurify, платформа "StudHub UA" забезпечує надійний захист від
більшості поширених векторів XSS-атак, пов'язаних з відображенням
користувацького контенту.
4.3 Захист від SQL-ін'єкцій
SQL-ін'єкція (SQL Injection, SQLi) є однією з найдавніших[17], але все
ще надзвичайно небезпечних атак на веб-застосунки, що взаємодіють з базами
даних. Суть атаки полягає у впровадженні зловмисних SQL-команд через
вхідні дані, які передаються від користувача до застосунку. Якщо ці дані без
належної обробки використовуються для динамічного формування SQL-
запитів, зловмисник може отримати можливість маніпулювати запитами до
бази даних. Це може призвести до несанкціонованого доступу до чутливої
інформації, модифікації або видалення даних, а в деяких випадках – навіть до
повного контролю над сервером бази даних.
У веб-додатку "StudHub UA" для взаємодії з базою даних PostgreSQL
використовується Object-Relational Mapper (ORM) SQLAlchemy[8].
Застосування ORM є одним з ключових та найефективніших методів захисту
від SQL-ін'єкцій.
Основні механізми захисту від SQL-ін'єкцій в "StudHub UA"
завдяки SQLAlchemy:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 41
1. Параметризовані запити (Prepared Statements):
SQLAlchemy за замовчуванням генерує параметризовані SQL-запити[8]
(також відомі як підготовлені вирази). При такому підході SQL-код
запиту та дані, що передаються в нього, розділені. Драйвер бази даних
спочатку отримує шаблон SQL-запиту з плейсхолдерами для значень,
компілює його, а потім окремо передає самі значення. Це унеможливлює
інтерпретацію користувацького вводу як частини виконуваного SQL-
коду. Навіть якщо користувач спробує ввести SQL-команди в поля
форми, вони будуть розглядатися системою бази даних просто як
рядкові дані, а не як інструкції.
o Приклад (концептуальний, як працює SQLAlchemy під
капотом):
Замість того, щоб формувати запит так:
query = f"SELECT * FROM users WHERE username =
'{user_input}'" (вразливо до ін'єкцій)
SQLAlchemy генерує щось на кшталт:
Шаблон: SELECT * FROM users WHERE username = %s
Дані: (user_input,)
Такий підхід є стійким до більшості атак SQL-ін'єкцій.
2. Абстракція від SQL:
При роботі з SQLAlchemy розробник взаємодіє з об'єктами Python
(моделями даних) та методами ORM, а не пише "сирі" SQL-запити
напряму. SQLAlchemy бере на себе відповідальність за коректну
генерацію SQL-коду на основі цих об'єктних операцій. Це значно
зменшує ймовірність випадкового створення вразливого SQL-коду через
помилки конкатенації рядків або неправильну обробку спеціальних
символів.
o Приклад (Python з SQLAlchemy):
# Замість написання SQL
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 42
# user = db.execute(f"SELECT * FROM users WHERE id =
{user_id}").first()
# використовується:
user = db.query(User).filter(User.id == user_id).first()
У другому випадку SQLAlchemy коректно обробить user_id.
3. Екранування спеціальних символів (якщо використовуються
літерали):
У рідкісних випадках, коли може знадобитися використання SQL-
літералів (що загалом не рекомендується при роботі з користувацьким
вводом), SQLAlchemy та драйвер бази даних (psycopg2 для PostgreSQL)
мають механізми для їх безпечного екранування[8, 11]. Однак, перевага
завжди надається параметризованим запитам.
4. Обмеження використання "сирих" SQL-запитів:
У проекті "StudHub UA" використання "сирих" SQL-запитів
(text() або execute() з рядковим SQL) зведено до абсолютного мінімуму
і застосовується лише там, де це дійсно необхідно і де вхідні дані не
походять безпосередньо від користувача або ретельно контролюються.
У всіх випадках взаємодії з даними, що можуть бути введені
користувачем (наприклад, параметри фільтрації, дані форм),
використовуються стандартні методи ORM.
Завдяки цим механізмам, вбудованим у SQLAlchemy, ризик успішної
SQL-ін'єкції в застосунку "StudHub UA" значно знижений. Важливою умовою
залишається послідовне використання можливостей ORM та уникнення
прямого формування SQL-запитів на основі неперевірених користувацьких
даних.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 43
4.4 Безпека автентифікації та авторизації
Надійна система автентифікації (перевірка особи користувача) та
авторизації (визначення прав доступу користувача до ресурсів та функцій) є
фундаментальною складовою безпеки веб-застосунку "StudHub UA".
Некоректна реалізація цих механізмів може призвести до несанкціонованого
доступу до чутливих даних, виконання дій від імені інших користувачів та
компрометації системи в цілому.
4.4.1 Автентифікація користувачів за допомогою JSON Web Tokens
(JWT)
Для автентифікації користувачів у "StudHub UA" було обрано механізм
на основі JSON Web Tokens (JWT)[16]. Цей підхід є сучасним стандартом для
веб-додатків, особливо тих, що мають RESTful API[15] та потенційно
взаємодіють з різними типами клієнтів (веб, мобільні).
Ключові аспекти реалізації JWT-автентифікації:
1. Процес отримання токена:
o Користувач надсилає свої облікові дані (email та пароль) на
спеціальний ендпоінт (/api/v1/auth/token).
o Сервер перевіряє валідність облікових даних, порівнюючи
наданий пароль з хешем пароля, збереженим у базі даних.
o У разі успішної автентифікації сервер генерує JWT (access token).
2. Структура Access Token:
o Згенерований access token містить закодовану інформацію
(payload) про користувача, необхідну для його ідентифікації та
авторизації при наступних запитах. У "StudHub UA" payload
токена включає:
 sub (subject): Email користувача.
 id: Унікальний ідентифікатор користувача в базі даних.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 44
 role: Роль користувача (наприклад, "student", "teacher",
"admin").
 exp: Час закінчення терміну дії токена.
o Токен підписується на сервері за допомогою секретного ключа
(SECRET_KEY) та алгоритму HMAC (наприклад, HS256[16], як
вказано в конфігурації ALGORITHM). Цей підпис гарантує
цілісність токена та те, що він не був змінений на стороні клієнта.
3. Термін дії Access Token:
o Access токени є короткоживучими (наприклад, 30 хвилин, як
визначено ACCESS_TOKEN_EXPIRE_MINUTES). Це зменшує
ризик у випадку компрометації токена, оскільки його дія буде
обмежена в часі.
4. Передача токена:
o Після успішної автентифікації access token надсилається клієнту.
o Клієнт (веб-інтерфейс) зберігає цей токен (наприклад,
у localStorage браузера) і повинен надсилати його з кожним
наступним запитом до захищених ендпоінтів API у HTTP-
заголовку Authorization за схемою Bearer:
Authorization: Bearer <your_access_token>
5. Валідація токена на сервері:
o При кожному запиті до захищеного ендпоінта FastAPI (за
допомогою залежностей, що
використовують OAuth2PasswordBearer) витягує токен із
заголовка Authorization[7, 20].
o Сервер перевіряє підпис токена за допомогою секретного ключа
та вказаного алгоритму.
o Перевіряється термін дії токена (exp).
o Якщо токен валідний, дані з payload (ID користувача, роль)
використовуються для ідентифікації та подальшої авторизації.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 45
Захист паролів:
Паролі користувачів ніколи не зберігаються у відкритому вигляді. Перед
збереженням у базу даних пароль хешується за допомогою надійного
алгоритму bcrypt, реалізованого через бібліотеку passlib. При спробі входу в
систему введений користувачем пароль хешується тим самим алгоритмом і
порівнюється зі збереженим хешем.
4.4.2 Авторизація на основі ролей
Після успішної автентифікації система повинна визначити, які дії та
ресурси доступні конкретному користувачеві. В "StudHub UA" реалізована
система авторизації на основі ролей:
1. Ролі користувачів:
o Система підтримує три основні
ролі: STUDENT, TEACHER, ADMIN (визначені
в app/models/user.py через enum UserRole).
o Роль користувача зберігається в базі даних та включається до
payload JWT-токена для швидкого доступу.
2. Захист ендпоінтів:
o Багато ендпоінтів API захищені таким чином, що доступ до них
дозволено лише користувачам з певними ролями. Це реалізовано
за допомогою кастомних залежностей FastAPI, таких
як require_admin, require_teacher, require_student, require_teacher_o
r_admin (визначені в app/routers/auth.py).
o Ці залежності використовують get_current_active_user для
отримання поточного користувача та перевіряють його
атрибут role. Якщо роль не відповідає вимогам ендпоінта,
повертається помилка HTTP 403 Forbidden.
3. Авторизація на рівні сервісів:
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 46
o Окрім захисту на рівні роутерів, перевірка прав доступу також
реалізована на рівні сервісних функцій. Наприклад, викладач
може редагувати тільки ті предмети або завдання, які він створив.
Студент може здавати роботу тільки на завдання своєї групи. Ці
перевірки здійснюються в бізнес-логіці сервісів (app/services/).
4.4.3 Подальші можливі покращення безпеки
автентифікації/авторизації
 Refresh Tokens: Для покращення користувацького досвіду та безпеки
можна було б впровадити механізм refresh токенів. Refresh токени є
довгоживучими і використовуються для безпечного отримання нових
access токенів без необхідності повторного введення пароля
користувачем. Це дозволяє робити access токени ще більш
короткоживучими.
 Двофакторна автентифікація (2FA): Для підвищення рівня захисту
облікових записів.
 Обмеження кількості спроб входу: Для захисту від атак перебору
паролів (brute-force).
 Більш гранульована система прав (Permissions): Замість або на
додаток до ролей можна було б реалізувати систему дозволів
(permissions), що дозволило б більш гнучко налаштовувати доступ до
окремих дій та ресурсів.
Реалізовані механізми автентифікації на основі JWT та авторизації за
ролями забезпечують базовий, але надійний рівень контролю доступу до
функціоналу та даних платформи "StudHub UA".
4.5 Захист від підробки міжсайтових запитів (CSRF)
Підробка міжсайтових запитів (Cross-Site Request Forgery, CSRF або
XSRF) – це тип атаки, при якій зловмисник змушує браузер автентифікованого
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 47
користувача виконати небажані дії на веб-сайті, де користувач вже має
активну сесію. Наприклад, якщо користувач залогінений на платформі
"StudHub UA", зловмисник може спробувати змусити його браузер надіслати
запит на зміну email або видалення публікації без відома та згоди користувача,
просто змусивши його перейти за спеціально сформованим посиланням або
відкрити сторінку зі шкідливим кодом.
Традиційно CSRF-атаки були більш актуальні для застосунків, що
використовують автентифікацію на основі сесійних cookie, оскільки браузери
автоматично надсилають cookie з кожним запитом до відповідного домену.
У веб-додатку "StudHub UA" для автентифікації використовується
механізм на основі JSON Web Tokens (JWT), які передаються в HTTP-
заголовку Authorization за схемою Bearer[16, 20]. Такий підхід сам по собі
значно знижує ризик традиційних CSRF-атак, оскільки:
1. Токени не надсилаються автоматично браузером: На відміну від
cookie, JWT, що зберігаються, наприклад,
у localStorage або sessionStorage на стороні клієнта, не надсилаються
автоматично з кожним запитом. Клієнтський JavaScript-код повинен
явно витягти токен зі сховища та додати його до
заголовка Authorization для кожного API-запиту, що вимагає
автентифікації. Це означає, що сторонній сайт не може просто змусити
браузер користувача надіслати запит з валідним токеном, якщо цей
токен не зберігається у вигляді cookie, доступного для міжсайтових
запитів.
2. Політика однакового походження (Same-Origin Policy, SOP): SOP
браузера обмежує можливість JavaScript-коду[12] з одного домену
робити запити до іншого домену. Хоча для API часто налаштовується
CORS (Cross-Origin Resource Sharing)[12] для дозволу запитів з певних
доменів, це не скасовує необхідності явної передачі токена.
Заходи, що сприяють захисту від CSRF в "StudHub UA":
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 48
 Використання JWT в заголовку Authorization: Як зазначено вище, це
основний механізм, що ускладнює CSRF.
 Відсутність використання сесійних cookie для автентифікації API:
Оскільки API не покладається на сесійні cookie для автентифікації,
традиційні вектори CSRF-атак, що експлуатують автоматичне
надсилання cookie, є менш ефективними.
 Перевірка Content-Type для запитів, що змінюють стан: Для запитів,
які змінюють дані (POST, PUT, PATCH, DELETE), FastAPI зазвичай
очікує Content-Type: application/json (якщо тіло запиту – JSON).
Зловмиснику складніше сформувати міжсайтовий запит з таким Content-
Type без використання JavaScript (наприклад, через просту HTML-
форму, яка зазвичай надсилає application/x-www-form-
urlencoded або multipart/form-data). Хоча це не є основним механізмом
захисту, це може створити додатковий бар'єр.
Потенційні вектори та додаткові міркування:
 Якщо JWT зберігається в cookie (не ваш випадок, але для повноти):
Якби JWT зберігався в cookie (особливо без
атрибутів HttpOnly та SameSite=Strict або SameSite=Lax), ризик CSRF
значно б зріс. У "StudHub UA" токен зберігається в localStorage, що не
піддається автоматичному надсиланню.
 CORS-конфігурація: Неправильна або надто дозвільна конфігурація
CORS може теоретично створити умови для деяких складних атак, але
сам по собі CORS не є прямим захистом від CSRF. Важливо, щоб CORS
був налаштований правильно, дозволяючи запити тільки з довірених
джерел.
 Захист від кліків (Clickjacking): Хоча це інший тип атаки, його іноді
згадують у контексті безпеки сесій. Використання заголовка X-Frame-
Options: DENY або Content-Security-Policy: frame-ancestors 'self' може
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 49
запобігти вбудовуванню сайту[12, 17] в <iframe> на зловмисних
ресурсах.
Висновок щодо CSRF:
Завдяки використанню JWT, що передаються через
заголовок Authorization і не зберігаються в автоматично надсиланих cookie,
ризик класичних CSRF-атак для API-ендпоінтів платформи "StudHub UA" є
низьким. Основний захист забезпечується тим, що для виконання будь-якої
значущої дії потрібна явна наявність валідного Bearer токена в запиті, який
сторонній сайт не може легко підробити або змусити браузер надіслати.
4.6 Безпека завантаження та обробки файлів
Функціонал завантаження файлів користувачами є невід'ємною
частиною платформи "StudHub UA", дозволяючи прикріплювати файли до
публікацій, умов завдань, зданих робіт та навчальних матеріалів. Однак, якщо
цей процес не контролюється належним чином, він може стати джерелом
серйозних вразливостей, таких як завантаження шкідливого програмного
забезпечення, файлів, що експлуатують вразливості на сервері (наприклад,
веб-оболонки), або файлів, що можуть спричинити XSS-атаки при їх
подальшому відображенні чи скачуванні (наприклад, спеціально сформовані
SVG або HTML файли).
Для забезпечення безпеки процесу завантаження та обробки файлів в
"StudHub UA" вжито наступні заходи:
1. Валідація типу файлів (MIME-типи та розширення):
o На стороні клієнта (JavaScript)
o На стороні сервера (Python/FastAPI)
2. Обмеження розміру файлів:
o Як на стороні клієнта (через перевірку file.size в JavaScript), так і
на стороні сервера встановлено максимальний дозволений розмір
файлу (MAX_FILE_SIZE). Це запобігає атакам типу "відмова в
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 50
обслуговуванні" (DoS) через завантаження надзвичайно великих
файлів, які можуть вичерпати дисковий простір або ресурси
сервера. Якщо розмір файлу перевищує ліміт, завантаження
відхиляється.
3. Генерація унікальних імен для збережених файлів:
o Щоб уникнути конфліктів імен та потенційних проблем безпеки,
пов'язаних з оригінальними іменами файлів (наприклад,
спеціальні символи, спроби перезаписати системні файли через
шляхи типу ../../filename), для кожного завантаженого файлу на
сервері генерується унікальне ім'я.
4. Зберігання файлів у спеціально відведеній директорії:
o Усі завантажені файли зберігаються у спеціально визначеній
директорії (uploads/) на сервері, яка знаходиться поза межами
директорій з виконуваним кодом застосунку. Ця директорія може
мати обмежені права доступу. Файли структурують за
піддиректоріями, що відповідають типу вкладення та ID
батьківського об'єкта
(наприклад, uploads/submission_attachments/SUBMISSION_ID/).
5. Контроль доступу при скачуванні файлів:
o Ендпоінти API, що відповідають за скачування файлів
(наприклад, /api/v1/attachments/submission/{attachment_id}/downlo
ad), реалізують перевірку прав доступу. Користувач може
завантажити файл, тільки якщо він має на це відповідні права
(наприклад, студент може завантажити файл зі своєї здачі або
файл завдання своєї групи; викладач – файли здач по своїх
завданнях або файли матеріалів, які він створив). Це запобігає
несанкціонованому доступу до файлів інших користувачів.
6. Сканування на віруси (потенційне майбутнє покращення):
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 51
o Для підвищення рівня безпеки, особливо якщо платформа буде
обробляти велику кількість файлів від багатьох користувачів,
можна розглянути інтеграцію з антивірусним сканером на сервері,
який би перевіряв усі завантажені файли на наявність шкідливого
ПЗ. На даному етапі розробки цей функціонал не реалізовано.
Рисунок 4.3 – Процес безпечного завантаження файлів
Вжиті заходи щодо валідації типів та розмірів файлів, використання
унікальних імен, контрольованого зберігання та перевірки прав доступу при
скачуванні значно знижують ризики, пов'язані з функціоналом завантаження
файлів на платформі "StudHub UA".
4.7 Використання HTTPS
Безпека даних під час їх передачі між клієнтом (браузером користувача)
та сервером є критично важливою. Незахищене HTTP-з'єднання дозволяє
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 52
зловмисникам перехоплювати та читати весь трафік, включаючи логіни,
паролі, сесійні токени та будь-яку іншу чутливу інформацію, що передається.
Для захисту даних "в дорозі" для платформи "StudHub UA" передбачається
використання протоколу HTTPS (HyperText Transfer Protocol Secure).
HTTPS є розширенням HTTP, яке використовує шифрування на основі
SSL/TLS (Secure Sockets Layer / Transport Layer Security) для створення
безпечного каналу зв'язку.
Ключові переваги використання HTTPS:
1. Шифрування даних: Весь трафік між клієнтом та сервером
шифрується, що робить його нечитабельним для третіх осіб, які можуть
намагатися перехопити дані (наприклад, при використанні публічних
Wi-Fi мереж). Це захищає облікові дані користувачів, JWT-токени та
будь-яку іншу інформацію, що передається.
2. Автентифікація сервера: SSL/TLS сертифікат, що використовується
для HTTPS, дозволяє клієнту перевірити автентичність сервера, до якого
він підключається. Це допомагає запобігти атакам типу "людина
посередині" (Man-in-the-Middle, MitM), коли зловмисник може видавати
себе за легітимний сервер.
3. Цілісність даних: HTTPS забезпечує перевірку цілісності даних,
гарантуючи, що інформація не була змінена під час передачі.
Реалізація HTTPS для "StudHub UA":
 Локальна розробка: Під час локальної розробки з
використанням uvicorn зазвичай використовується HTTP, оскільки
налаштування локального HTTPS-сертифіката може бути надлишковим
для цього етапу. uvicorn може бути запущений з SSL, якщо надати йому
шляхи до файлів сертифіката та приватного ключа, але для простоти
розробки це часто опускається.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 53
 Продакшн-середовище (Heroku): При розгортанні веб-додатку
"StudHub UA" на хмарній платформі, такій як Heroku, HTTPS зазвичай
налаштовується та керується самою платформою. Heroku надає
автоматичні SSL-сертифікати для додатків, що використовують
стандартні домени (*.herokuapp.com), а також дозволяє налаштовувати
власні SSL-сертифікати для кастомних доменів. Таким чином, для
користувачів, що взаємодіють з розгорнутим на Heroku додатком,
з'єднання автоматично відбувається через HTTPS.
Використання HTTPS є обов'язковою практикою для будь-якого веб-
застосунку, що обробляє автентифікаційні дані або будь-яку іншу
конфіденційну інформацію, і є невід'ємною частиною стратегії безпеки
платформи "StudHub UA" у робочому середовищі.
4.8 Висновки до розділу безпеки
Забезпечення належного рівня безпеки є одним із пріоритетних завдань
при розробці будь-якого веб-застосунку, особливо такого, як освітня
платформа "StudHub UA", що призначена для обробки даних користувачів та
навчальної інформації. У цьому розділі було розглянуто ключові аспекти
безпеки, враховані під час проектування та реалізації системи.
Було проаналізовано основні типи загроз, характерні для сучасних веб-
додатків, та впроваджено комплекс заходів для їх мінімізації:
1. Захист від міжсайтового скриптингу (XSS) реалізовано шляхом
ретельної обробки та санітизації даних, що вводяться користувачами,
перед їх відображенням. Для виводу простого тексту використовується
властивість textContent, а для контенту, що підтримує форматування
Markdown, застосовується комбінація бібліотек Showdown.js для
конвертації в HTML та DOMPurify.js для подальшої санітизації
згенерованого HTML.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 54
2. Захист від SQL-ін'єкцій забезпечується завдяки використанню Object-
Relational Mapper (ORM) SQLAlchemy, який за замовчуванням генерує
параметризовані запити до бази даних PostgreSQL, унеможливлюючи
інтерпретацію користувацького вводу як виконуваного SQL-коду.
3. Безпека автентифікації та авторизації побудована на основі
механізму JSON Web Tokens (JWT). Паролі користувачів хешуються за
допомогою bcrypt. Доступ до ресурсів та функціоналу системи
контролюється на основі ролей користувачів (студент, викладач,
адміністратор) як на рівні API ендпоінтів, так і в бізнес-логіці сервісного
шару.
4. Зниження ризику CSRF-атак досягається завдяки використанню JWT,
що передаються в HTTP-заголовку Authorization, а не через автоматично
надсилані сесійні cookie.
5. Безпека завантаження файлів забезпечується багатоетапною
валідацією (тип, розмір) як на клієнтській, так і на серверній стороні (з
використанням python-magic), генерацією унікальних імен для
збережених файлів, зберіганням у спеціально відведеній директорії та
контролем доступу при їх скачуванні.
6. Захист конфігураційних даних та секретів реалізовано шляхом їх
винесення з коду програми у змінні середовища та використання
файлу .env для локальної розробки (з виключенням його із системи
контролю версій).
7. Забезпечення конфіденційності даних під час
передачі передбачається шляхом використання протоколу HTTPS у
робочому середовищі, що забезпечує шифрування трафіку між клієнтом
та сервером.
Впроваджені заходи створюють надійну основу для безпечного
функціонування платформи "StudHub UA". Важливо розуміти, що безпека –
це безперервний процес, який вимагає постійної уваги, моніторингу,
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 55
регулярного оновлення програмних компонентів та адаптації до нових
потенційних загроз. Подальший розвиток системи може включати
впровадження додаткових механізмів захисту, таких як двофакторна
автентифікація, більш гранульована система прав доступу та налаштування
Content Security Policy.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 56
5 ВИКОРИСТАННЯ ТА ТЕСТУВАННЯ ДОДАТКУ
5.1 Розгортання та запуск
У процесі розробки веб-додатку "StudHub UA" я застосував поетапний
підхід до його розгортання та тестування. Основна частина розробки
проводилася в локальному середовищі з використанням вбудованого ASGI-
сервера uvicorn, що дозволило мені швидко ітерувати зміни та виправляти
помилки без потреби у постійному розгортанні на віддаленому сервері.
Для промислової експлуатації я вибрав хмарну платформу Heroku
завдяки її простоті у використанні, автоматизованому розгортанню з GitHub
репозиторію та наявності інтегрованих сервісів, зокрема бази даних
PostgreSQL. Такий підхід дозволив мені зосередитись на розробці
функціональності, а не на налаштуванні інфраструктури.
Розгортання додатку супроводжувалося налаштуванням змінних
середовища для збереження конфіденційних даних (секретних ключів JWT,
параметрів підключення до бази даних), створенням міграцій Alembic та
налаштуванням автоматичного застосування цих міграцій при кожному
оновленні додатку на сервері. Детальна інструкція з розгортання представлена
у Додатку Д.
5.2 Приклади використання API
Розроблений API забезпечує повний спектр функціональності,
необхідної для роботи системи. Взаємодія з API здійснюється за допомогою
стандартних HTTP-запитів що відповідає принципам RESTful[15] та
забезпечує інтероперабельність та можливість інтеграції з різними
клієнтськими додатками. Далі наведено основні приклади використання API.
Реєстрація користувача:
curl -X POST "[BASE_URL]/api/v1/auth/register" \
-H "Content-Type: application/json" \
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 57
-d '{"email": "[email protected]", "password": "password123"}'
Автентифікація та отримання токена:
curl -X POST "[BASE_URL]/api/v1/auth/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "[email protected]&password=password123"
Отримання інформації про власний профіль:
curl -X GET "[BASE_URL]/api/v1/users/me" \
-H "Authorization: Bearer <YOUR_ACCESS_TOKEN>"
Створення публікації:
curl -X POST "[BASE_URL]/api/v1/posts/" \
-H "Authorization: Bearer <YOUR_ACCESS_TOKEN>" \
-H "Content-Type: application/json" \
-d '{"title": "Заголовок публікації", "content": "Текст публікації"}'
Отримання розкладу для конкретної групи на певну дату:
curl -X GET "[BASE_URL]/api/v1/schedules/?group_id=1&start_date=2024-09-
03&end_date=2024-09-03"
5.3 Опис основних сценаріїв роботи користувачів
В процесі проектування я визначив три ключові ролі користувачів з
відповідними сценаріями використання:
Студент:
1. Реєстрація у системі або вхід з існуючими обліковими даними
2. Заповнення даних профілю та вибір академічної групи
3. Перегляд розкладу занять для своєї групи
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 58
4. Перегляд матеріалів до заняття
5. Перегляд та здача завдання по заняттю
6. Перегляд стрічки публікацій (загальних та пов'язаних з групою)
7. Взаємодія з публікаціями (коментування, вподобання)
8. Створення власних публікацій для обміну інформацією
Викладач:
1. Вхід у систему (реєстрація викладачів здійснюється адміністратором)
2. Керування групами, з якими працює викладач
3. Додавання та редагування навчальних дисциплін
4. Керування розкладом занять (додавання, редагування, видалення)
5. Керування матеріалами по заняттю та створення завдань з можливістю
обговорення роботи
6. Створення оголошень для студентів
7. Відповіді на запитання студентів у коментарях
Адміністратор:
1. Вхід до системи з правами адміністратора
2. Робота з адміністративною панеллю
3. Керування користувачами (зміна ролей, активація/деактивація
облікових записів)
4. Створення та редагування академічних груп
5. Моніторинг активності у системі
Особливу увагу я приділив зручності використання системи студентами,
оскільки вони є основною цільовою аудиторією. Інтерфейс розроблено з
урахуванням мобільного доступу, що дозволяє користуватись додатком як з
комп'ютера, так і зі смартфона.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 59
5.4 Підходи до тестування
Тестування системи проводилося на різних етапах розробки з
використанням комплексного підходу:
1. Модульне тестування: Я зосередився на перевірці коректності роботи
окремих функцій, особливо у сервісному шарі, де зосереджена бізнес-
логіка. Тестувалися функції обробки даних, валідації вхідних
параметрів, хешування паролів та генерації JWT-токенів.
2. Інтеграційне тестування: Перевірялася взаємодія між сервісним
шаром та шаром доступу до даних через ORM SQLAlchemy.
3. Тестування API: Цей вид тестування був основним у процесі розробки.
Я систематично перевіряв:
o Коректність статус-кодів відповідей для різних сценаріїв (200,
201, 204, 400, 401, 403, 404, 422)
o Структуру та типи даних у JSON-відповідях (відповідність
Pydantic схемам)
o Обробку коректних та некоректних вхідних даних
o Функціонування механізмів автентифікації (JWT) та авторизації
(перевірка ролей)
Для цього використовувалась інтерактивна документація Swagger
UI.
4. Тестування інтерфейсу користувача: Проводилося вручну шляхом
виконання типових сценаріїв для кожної ролі користувача.
Перевірялася:
o Коректність відображення даних
o Функціонування форм введення
o Навігація між розділами
o Обробка помилок на клієнтській стороні
o Адаптивність інтерфейсу для різних пристроїв
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 60
Додатково після кожного розгортання на Heroku
проводилося тестування для перевірки базової працездатності системи у
промисловому середовищі.
Такий підхід до тестування дозволив мені своєчасно виявляти та
виправляти помилки, забезпечуючи стабільну роботу додатку.
5.5 Висновки до розділу
У даному розділі я описав практичні аспекти використання та
тестування веб-додатку "StudHub UA". Система розгорнута на хмарній
платформі Heroku з використанням інтегрованої бази даних PostgreSQL, що
забезпечує стабільну роботу та високу доступність сервісу.
Комплексний підхід до тестування, що включав модульне, інтеграційне,
API та UI тестування, забезпечив надійність та стабільність роботи додатку.
Наведені приклади API-запитів ілюструють простоту взаємодії з системою та
її можливості.
В цілому, розроблений веб-додаток є готовим до розширення
функціональності, зокрема в напрямках організації спільних проектів,
створення публічних сторінок користувачів.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 61
ВИСНОВКИ
У результаті виконання даної кваліфікаційної роботи було спроектовано
та реалізовано серверну частину та базовий веб-інтерфейс для інтегрованої
університетської платформи "StudHub UA". Робота була спрямована на
вирішення проблеми фрагментації цифрових інструментів в освітньому
процесі шляхом створення єдиного інформаційно-комунікаційного простору.
Основні результати роботи:
– Проведено аналіз предметної області, виявлено недоліки існуючих
підходів до організації навчального процесу та комунікації в ЗВО.
– Обґрунтовано вибір сучасного технологічного стеку, що забезпечує
продуктивність, надійність та швидкість розробки.
– Спроектовано масштабовану клієнт-серверну архітектуру з RESTful API
та розроблено реляційну модель бази даних для зберігання ключової
інформації.
– Реалізовано основний функціонал серверної частини, включаючи: систему
автентифікації/авторизації, керування користувачами, групами,
предметами, систему перегляду та керування розкладом, платформу для
публікацій з коментарями, лайками та вкладеннями.
– Розроблено адміністративну панель для керування основними сутностями
системи.
– Налаштовано систему міграцій бази даних за допомогою Alembic.
– Створено базовий веб-інтерфейс для демонстрації роботи API та основних
функцій платформи.
– Описано та апробовано процес розробки, локального тестування (API, UI)
та розгортання додатку на хмарній платформі Heroku з використанням
Heroku Postgres.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 62
Розроблений прототип "StudHub UA" демонструє потенціал
інтегрованого підходу, надаючи користувачам централізований доступ до
розкладу, засобів комунікації та адміністрування навчальних даних.
Таким чином, мета кваліфікаційної роботи була досягнута: створено
програмне забезпечення, що закладає основу для єдиної університетської
платформи та вирішує актуальні проблеми організації освітнього процесу.
Лист
ЧДТУ.252179.003 ПЗ т
Зм. Лист № докум. Підпис Дата 63
ДОДАТОК А
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор Віра БАБЕНКО
__________________
«___» ____________ 2025 року
Вебзастосунок для обміну інформацією та організації роботи
студента
Специфікація
482.ЧДТУ.52179-01
Листів 4
Розробник _______________ Сергій ДОННЕР
Керівник _______________ Валерій ТАЗЕТДІНОВ
Черкаси 2025
2
482.ЧДТУ.52179-01
Позначення Найменування Примітка
Документація
482.ЧДТУ.52179-01 12 01 Текст програми
482.ЧДТУ.52179-01 13 01 Опис бази даних
482.ЧДТУ.5217901 32 01 Інструкція системного
програміста
482.ЧДТУ.52179-01 34 01 Інструкція користувача
В додатку наведена документація згенерована автоматично FastAPI за
допомогою Swagger UI, інтерактивна документація доступна за адресою
https://studhub-5ed599d130f4.herokuapp.com/docs

ДОДАТОК Б
Вебзастосунок для обміну інформацією та організації роботи
студента
Текст програми
482.ЧДТУ.52179-01 12 01
Листів 12
Розробник: _________________ Сергій ДОННЕР
Черкаси 2025
2
482.ЧДТУ.52179-01 12 01
У цьому додатку наведено фрагменти програмного коду, що
ілюструють ключові аспекти реалізації серверної частини вебзастосунку
"StudHub UA".
Текст програми «Модель даних користувача» (app/models/user.py)
# app/models/user.py
import enum
from sqlalchemy import (
Column, Integer, String, Boolean, DateTime, Enum as SQLEnum, ForeignKey,
Index
)
from sqlalchemy.orm import relationship
from sqlalchemy.sql import func
from app.core.database import Base
from app.models.associations import teacher_group_association_table
class UserRole(str, enum.Enum):
STUDENT = "student"
TEACHER = "teacher"
ADMIN = "admin"
class User(Base):
__tablename__ = "users"
id = Column(Integer, primary_key=True, index=True)
email = Column(String, unique=True, index=True, nullable=False)
hashed_password = Column(String, nullable=False)
first_name = Column(String, index=True, nullable=True)
last_name = Column(String, index=True, nullable=True)
role = Column(SQLEnum(UserRole, name="user_role_enum"), nullable=False,
index=True)
is_active = Column(Boolean, default=True, nullable=False)
group_id = Column(Integer, ForeignKey("groups.id", ondelete="SET NULL"),
nullable=True, index=True)
created_at = Column(DateTime(timezone=True), server_default=func.now(),
nullable=False)
updated_at = Column(DateTime(timezone=True), server_default=func.now(),
onupdate=func.now(), nullable=False)
# Зв'язки ORM
group = relationship("Group", back_populates="students")
3
482.ЧДТУ.52179-01 12 01
teaching_groups = relationship(
"Group",
secondary=teacher_group_association_table,
back_populates="teachers"
)
subjects = relationship("Subject", back_populates="teacher", cascade="all,
delete-orphan")
posts = relationship("Post", back_populates="author", cascade="all, delete-
orphan")
comments = relationship("Comment", back_populates="author", cascade="all,
delete-orphan")
# Інші зв'язки (likes, attachments)...
def __repr__(self):
return f"<User(id={self.id}, email='{self.email}', role='{self.role.value}')>"
Index('ix_user_role', User.role) # Додатковий індекс для ролі
Текст програми «Модель розкладу» (app/models/schedule.py)
# app/models/schedule.py
from sqlalchemy import (
Column, Integer, String, Enum as SQLEnum, ForeignKey, Date, Time,
UniqueConstraint, Index
)
from sqlalchemy.orm import relationship
from app.core.database import Base
from app.models.enums import LessonType # Enum типів занять
class Schedule(Base):
__tablename__ = "schedules"
id = Column(Integer, primary_key=True, index=True)
lesson_date = Column(Date, nullable=False, index=True) # Дата заняття
slot_number = Column(Integer, nullable=False, index=True) # Номер пари
location = Column(String, nullable=True) # Аудиторія / посилання
lesson_type = Column(SQLEnum(LessonType, name="lesson_type_enum"),
nullable=True)
# Зовнішні ключі
group_id = Column(Integer, ForeignKey("groups.id", ondelete="CASCADE"),
nullable=False, index=True)
4
482.ЧДТУ.52179-01 12 01
subject_id = Column(Integer, ForeignKey("subjects.id",
ondelete="CASCADE"), nullable=False, index=True)
# Зв'язки ORM
group = relationship("Group")
subject = relationship("Subject")
# Обмеження унікальності: одна група не може мати два заняття на одну
дату/слот
__table_args__ = (UniqueConstraint('lesson_date', 'slot_number', 'group_id',
name='uq_schedule_date_slot_group'),)
def __repr__(self):
return f"<Schedule(id={self.id}, date='{self.lesson_date}',
slot={self.slot_number})>"
# Індекси для швидкого пошуку
Index('ix_schedule_group_date', Schedule.group_id, Schedule.lesson_date)
Index('ix_schedule_subject_date', Schedule.subject_id, Schedule.lesson_date)
Текст програми «Модель публікації» (app/models/post.py)
# app/models/post.py
from sqlalchemy import Column, Integer, String, Text, ForeignKey, DateTime,
Index, func
from sqlalchemy.orm import relationship
from app.core.database import Base
class Post(Base):
__tablename__ = "posts"
id = Column(Integer, primary_key=True, index=True)
title = Column(String(255), nullable=False, index=True)
content = Column(Text, nullable=False)
author_id = Column(Integer, ForeignKey("users.id", ondelete="CASCADE"),
nullable=False, index=True)
# Час останньої активності (оновлюється при коментуванні)
last_activity_at = Column(DateTime(timezone=True),
server_default=func.now(), nullable=False, index=True)
created_at = Column(DateTime(timezone=True), server_default=func.now(),
nullable=False)
updated_at = Column(DateTime(timezone=True), server_default=func.now(),
onupdate=func.now(), nullable=False)
5
482.ЧДТУ.52179-01 12 01
# Зв'язки ORM
author = relationship("User", back_populates="posts")
comments = relationship("Comment", back_populates="post", cascade="all,
delete-orphan", order_by="Comment.created_at")
likes = relationship("PostLike", cascade="all, delete-orphan") # back_populates
можна додати в PostLike
attachments = relationship("PostAttachment", back_populates="post",
cascade="all, delete-orphan")
def __repr__(self):
return f"<Post(id={self.id}, title='{self.title}', author_id={self.author_id})>"
Текст програми «Модель публікації» (app/models/post.py)
# app/models/post.py
from sqlalchemy import Column, Integer, String, Text, ForeignKey, DateTime,
Index, func
from sqlalchemy.orm import relationship
from app.core.database import Base
class Post(Base):
__tablename__ = "posts"
id = Column(Integer, primary_key=True, index=True)
title = Column(String(255), nullable=False, index=True)
content = Column(Text, nullable=False)
author_id = Column(Integer, ForeignKey("users.id", ondelete="CASCADE"),
nullable=False, index=True)
# Час останньої активності (оновлюється при коментуванні)
last_activity_at = Column(DateTime(timezone=True),
server_default=func.now(), nullable=False, index=True)
created_at = Column(DateTime(timezone=True), server_default=func.now(),
nullable=False)
updated_at = Column(DateTime(timezone=True), server_default=func.now(),
onupdate=func.now(), nullable=False)
# Зв'язки ORM
author = relationship("User", back_populates="posts")
comments = relationship("Comment", back_populates="post", cascade="all,
delete-orphan", order_by="Comment.created_at")
likes = relationship("PostLike", cascade="all, delete-orphan")
attachments = relationship("PostAttachment", back_populates="post",
cascade="all, delete-orphan")
6
482.ЧДТУ.52179-01 12 01
def __repr__(self):
return f"<Post(id={self.id}, title='{self.title}', author_id={self.author_id})>"
Текст програми «Схеми для користувача» (app/schemas/user.py)
# app/schemas/user.py
from pydantic import BaseModel, EmailStr, ConfigDict, Field
from typing import Optional, List
from datetime import datetime
from app.models.user import UserRole # Або з enums.py
from app.schemas.group import GroupRead # Імпорт схеми групи
class UserBase(BaseModel):
# Базова схема з полями, спільними для різних операцій
email: EmailStr
first_name: Optional[str] = None
last_name: Optional[str] = None
model_config = ConfigDict(from_attributes=True) # Дозволяє створювати
схему з ORM об'єкта
class UserCreate(UserBase):
# Схема для створення нового користувача (реєстрація)
password: str = Field(..., min_length=8) # Пароль обов'язковий
class UserUpdateMe(BaseModel):
# Схема для оновлення власного профілю
email: Optional[EmailStr] = None
first_name: Optional[str] = None
last_name: Optional[str] = None
class UserUpdateAdmin(UserUpdateMe):
# Схема для оновлення користувача адміном (додаткові поля)
role: Optional[UserRole] = None
is_active: Optional[bool] = None
group_id: Optional[int | None] = None # Можна призначити групу або зняти
(None)
class UserRead(UserBase):
# Схема для представлення даних користувача у відповідях API
id: int
role: UserRole
is_active: bool
7
482.ЧДТУ.52179-01 12 01
created_at: datetime
group: Optional[GroupRead] = None # Включаємо дані групи студента
# Схеми для токенів
class Token(BaseModel):
access_token: str
token_type: str
class TokenData(BaseModel):
# Дані, що зберігаються всередині JWT токену
email: Optional[str] = None
id: Optional[int] = None
role: Optional[UserRole] = None
Текст програми «Схеми для розкладу» (app/schemas/schedule.py)
# app/schemas/schedule.py
from pydantic import BaseModel, ConfigDict, Field
from typing import Optional
from datetime import date, time
from app.models.enums import LessonType
from app.schemas.group import GroupRead
from app.schemas.subject import SubjectRead
from app.core.constants import LESSON_SLOTS # Для валідації слоту
class ScheduleBase(BaseModel):
# Базова схема для створення/оновлення запису розкладу
lesson_date: date
slot_number: int = Field(..., ge=1, le=len(LESSON_SLOTS)) # Номер пари (1-
9)
group_id: int = Field(..., gt=0) # ID групи
subject_id: int = Field(..., gt=0) # ID предмету
location: Optional[str] = Field(None, max_length=255) # Аудиторія/посилання
lesson_type: Optional[LessonType] = None # Тип заняття (лекція, практика і
т.д.)
class ScheduleCreate(ScheduleBase):
# Схема для створення нового запису (приймається API)
pass
class ScheduleUpdate(BaseModel):
# Схема для оновлення існуючого запису (PATCH) - тільки неключові поля
location: Optional[str] = Field(None, max_length=255)
8
482.ЧДТУ.52179-01 12 01
lesson_type: Optional[LessonType] = None
# Зміна дати, слоту, групи, предмету не рекомендована через PATCH
class ScheduleRead(ScheduleBase):
# Схема для представлення запису розкладу (повертається API)
id: int
# Додаємо пов'язані об'єкти для повної інформації
group: Optional[GroupRead] = None
subject: Optional[SubjectRead] = None
model_config = ConfigDict(from_attributes=True)
class ScheduleReadWithTimes(ScheduleRead):
# Розширена схема, що додає час початку/кінця пари (обчислюється в
роутері)
start_time: Optional[time] = None
end_time: Optional[time] = None
Текст програми «Функція отримання розкладу за критеріями»
(app/services/schedule_service.py)
# app/services/schedule_service.py (Фрагмент)
from sqlalchemy.orm import Session, joinedload
from sqlalchemy import and_
from typing import List, Optional
from datetime import date
from app.models import Schedule, Subject, User # Імпортуємо необхідні моделі
def get_schedule_by_criteria(
db: Session,
start_date: date,
end_date: date,
group_id: Optional[int] = None,
teacher_id: Optional[int] = None,
subject_id: Optional[int] = None,
) -> List[Schedule]:
"""
Отримує список записів розкладу за діапазоном дат та іншими критеріями.
Використовує joinedload для ефективного завантаження пов'язаних даних.
"""
query = db.query(Schedule).options(
joinedload(Schedule.group), # Завантажуємо дані групи
9
482.ЧДТУ.52179-01 12 01
joinedload(Schedule.subject).joinedload(Subject.teacher) # Завантажуємо
предмет і його викладача
).filter(
Schedule.lesson_date >= start_date,
Schedule.lesson_date <= end_date
)
# Застосовуємо фільтри, якщо вони передані
if group_id is not None:
query = query.filter(Schedule.group_id == group_id)
if subject_id is not None:
query = query.filter(Schedule.subject_id == subject_id)
if teacher_id is not None:
# Фільтруємо по ID викладача через зв'язок з предметом
query = query.join(Schedule.subject).filter(Subject.teacher_id == teacher_id)
# Сортуємо за датою та номером слоту
query = query.order_by(Schedule.lesson_date, Schedule.slot_number)
return query.all() # Повертаємо список об'єктів Schedule
Текст програми «Функція отримання постів»
(app/services/post_service.py)
# app/services/post_service.py (Фрагмент)
from sqlalchemy.orm import Session, joinedload, selectinload
from sqlalchemy import desc, func, select
from typing import List, Optional
from app.models import Post, Comment, PostLike, User # Імпортуємо моделі
def get_posts(db: Session, sort_by: str = "activity", skip: int = 0, limit: int = 20) ->
List[Post]:
"""Отримує список постів з сортуванням та підрахунком
лайків/коментарів."""
# Підзапит для підрахунку лайків
like_subquery = (
select(PostLike.post_id, func.count(PostLike.user_id).label("like_count"))
.group_by(PostLike.post_id).subquery().alias("likes_sq")
)
# Підзапит для підрахунку коментарів
comment_subquery = (
select(Comment.post_id, func.count(Comment.id).label("comment_count"))
10
482.ЧДТУ.52179-01 12 01
.group_by(Comment.post_id).subquery().alias("comments_sq")
)
# Основний запит до постів
query = db.query(
Post,
func.coalesce(like_subquery.c.like_count, 0).label("likes_count"), #
Кількість лайків (0, якщо немає)
func.coalesce(comment_subquery.c.comment_count,
0).label("comments_count") # Кількість коментарів
).options(joinedload(Post.author)) # Завантажуємо автора поста одразу
# Приєднуємо підзапити через LEFT JOIN
query = query.outerjoin(like_subquery, Post.id == like_subquery.c.post_id)
query = query.outerjoin(comment_subquery, Post.id ==
comment_subquery.c.post_id)
# Застосовуємо сортування
if sort_by == "likes":
query = query.order_by(desc("likes_count"), desc(Post.last_activity_at))
elif sort_by == "comments":
query = query.order_by(desc("comments_count"), desc(Post.last_activity_at))
else: # Сортування за активністю (за замовчуванням)
query = query.order_by(desc(Post.last_activity_at))
# Застосовуємо пагінацію
results = query.offset(skip).limit(limit).all()
# Додаємо підраховані значення до об'єктів Post
posts = []
for post, likes_count, comments_count in results:
post.likes_count = likes_count
post.comment_count = comments_count
posts.append(post)
return posts
Текст програми «Ендпоінт отримання розкладу»
(app/routers/schedule.py)
# app/routers/schedule.py
from fastapi import APIRouter, Depends, HTTPException, status, Query
from sqlalchemy.orm import Session
from typing import List, Optional
11
482.ЧДТУ.52179-01 12 01
from datetime import date, time
from app.core.database import get_db
from app.schemas.schedule import ScheduleReadWithTimes
from app.services import schedule_service
from app.core.constants import get_slot_times
from app.models import Schedule
router = APIRouter(prefix="/schedules", tags=["Schedules"])
def enrich_schedule_with_times(schedule: Schedule) -> dict:
schedule_dict = ScheduleRead.model_validate(schedule).model_dump()
slot_times = get_slot_times(schedule.slot_number)
schedule_dict["start_time"] = slot_times[0] if slot_times else None
schedule_dict["end_time"] = slot_times[1] if slot_times else None
# Додаємо інформацію про викладача з предмета
if schedule.subject and schedule.subject.teacher:
from app.schemas.user import UserRead as UserReadSchema # Імпортуємо
всередині, щоб уникнути циклічності
teacher_data =
UserReadSchema.model_validate(schedule.subject.teacher).model_dump(exclude
={'group', 'teaching_groups', 'subjects'})
if schedule_dict.get("subject"):
schedule_dict["subject"]["teacher"] = teacher_data
return schedule_dict
@router.get("/", response_model=List[ScheduleReadWithTimes]) #
Використовуємо розширену схему
async def read_schedule_by_filter(
start_date: date = Query(..., description="Початкова дата періоду (YYYY-
MM-DD)"),
end_date: date = Query(..., description="Кінцева дата періоду (YYYY-MM-
DD)"),
group_id: Optional[int] = Query(None, gt=0),
teacher_id: Optional[int] = Query(None, gt=0),
subject_id: Optional[int] = Query(None, gt=0),
db: Session = Depends(get_db),
):
"""Отримує список записів розкладу за критеріями."""
if start_date > end_date:
raise HTTPException(status_code=status.HTTP_400_BAD_REQUEST,
detail="Start date cannot be after end date.")
# Отримуємо дані з сервісу
12
482.ЧДТУ.52179-01 12 01
schedules = schedule_service.get_schedule_by_criteria(
db=db, start_date=start_date, end_date=end_date, group_id=group_id,
teacher_id=teacher_id, subject_id=subject_id
)
# додаємо час запису початку/кінця перед відправкою
response_data = [enrich_schedule_with_times(s) for s in schedules]
return response_data
ДОДАТОК Б
Вебзастосунок для обміну інформацією та організації роботи
студента
Опис бази даних
482.ЧДТУ.52179-01 13 01
Листів 12
Розробник: _________________ Сергій ДОННЕР
Черкаси 2025
2
482.ЧДТУ.52179-01 13 01
СХЕМА БАЗИ ДАНИХ
Блок схема В.1 – Схема сутностей та зв’язків
3
482.ЧДТУ.52179-01 13 01
ОПИС ТАБЛИЦЬ
users
 Призначення: Зберігання інформації про користувачів системи
(студентів, викладачів, адміністраторів).
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o group_id (INTEGER, Nullable, Foreign Key -> groups.id, ON
DELETE SET NULL, Index: ix_users_group_id)
o created_at (TIMESTAMP, Not Null, Default: now())
o first_name (VARCHAR, Nullable, Index: ix_users_first_name)
o hashed_password (VARCHAR, Not Null)
o is_active (BOOLEAN, Not Null, Default: true)
o email (VARCHAR, Unique, Not Null, Index: ix_users_email)
o last_name (VARCHAR, Nullable, Index: ix_users_last_name)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
o role (VARCHAR, Not Null, Index: ix_users_role) - Може бути
реалізовано як ENUM('student', 'teacher', 'admin')
groups
 Призначення: Зберігання інформації про академічні групи.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o course (INTEGER, Nullable, Index: ix_groups_course)
o name (VARCHAR, Unique, Not Null, Index: ix_groups_name)
 Додаткові індекси: ix_groups_name_pattern (для пошуку за шаблоном,
якщо реалізовано).
4
482.ЧДТУ.52179-01 13 01
teacher_group_association
 Призначення: Асоціативна таблиця для зв'язку Many-to-Many між
викладачами (users.role='teacher') та групами.
 Колонки:
o group_id (INTEGER, Primary Key, Foreign Key -> groups.id, ON
DELETE CASCADE, Index)
o teacher_id (INTEGER, Primary Key, Foreign Key -> users.id, ON
DELETE CASCADE, Index)
subjects
 Призначення: Зберігання інформації про навчальні предмети.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o teacher_id (INTEGER, Not Null, Foreign Key -> users.id, ON
DELETE CASCADE, Index: ix_subjects_teacher_id)
o created_at (TIMESTAMP, Not Null, Default: now())
o description (TEXT, Nullable)
o name (VARCHAR, Not Null, Index: ix_subjects_name)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
posts
 Призначення: Зберігання публікацій (наприклад, оголошень, новин).
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o author_id (INTEGER, Not Null, Foreign Key -> users.id, ON
DELETE CASCADE, Index: ix_posts_author_id)
o content (TEXT, Not Null)
o created_at (TIMESTAMP, Not Null, Default: now())
o last_activity_at (TIMESTAMP, Not Null, Default: now(), Index:
ix_posts_last_activity_at)
5
482.ЧДТУ.52179-01 13 01
o title (VARCHAR(255), Not Null)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
comments
 Призначення: Зберігання коментарів до публікацій.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o author_id (INTEGER, Not Null, Foreign Key -> users.id, ON
DELETE CASCADE, Index: ix_comments_author_id)
o content (TEXT, Not Null)
o created_at (TIMESTAMP, Not Null, Default: now())
o parent_id (INTEGER, Nullable, Foreign Key -> comments.id, ON
DELETE CASCADE, Index: ix_comments_parent_id)
o post_id (INTEGER, Not Null, Foreign Key -> posts.id, ON DELETE
CASCADE, Index: ix_comments_post_id)
post_likes
 Призначення: Зберігання "лайків" до публікацій.
 Колонки:
o post_id (INTEGER, Primary Key, Foreign Key -> posts.id, ON
DELETE CASCADE)
o user_id (INTEGER, Primary Key, Foreign Key -> users.id, ON
DELETE CASCADE)
o created_at (TIMESTAMP, Not Null, Default: now())
 Обмеження: UNIQUE constraint (user_id, post_id)
post_attachments
 Призначення: Зберігання метаданих файлів, прикріплених до
публікаций.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
6
482.ЧДТУ.52179-01 13 01
o post_id (INTEGER, Not Null, Foreign Key -> posts.id, ON DELETE
CASCADE, Index: ix_post_attachments_post_id)
o filename (VARCHAR, Not Null)
o filepath (VARCHAR, Not Null, Unique)
o filesize (BIGINT, Nullable)
o mimetype (VARCHAR, Nullable)
o uploaded_at (TIMESTAMP, Not Null, Default: now())
o uploader_id (INTEGER, Nullable, Foreign Key -> users.id, ON
DELETE SET NULL)
schedules
 Призначення: Зберігання записів розкладу занять.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o group_id (INTEGER, Not Null, Foreign Key -> groups.id, ON
DELETE CASCADE, Index: ix_schedules_group_id_lesson_date)
o subject_id (INTEGER, Not Null, Foreign Key -> subjects.id, ON
DELETE CASCADE, Index: ix_schedules_subject_id)
o created_at (TIMESTAMP, Not Null, Default: now())
o lesson_date (DATE, Not Null, Index: ix_schedules_lesson_date)
o lesson_type (VARCHAR, Nullable) - Може бути реалізовано як
ENUM('lecture', 'practice', ...)
o location (VARCHAR, Nullable)
o slot_number (INTEGER, Not Null, Index: ix_schedules_slot_number)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
 Обмеження: UNIQUE constraint (lesson_date, slot_number, group_id)
 Додаткові індекси: ix_schedule_group_date (на group_id, lesson_date),
ix_schedule_subject_date (на subject_id, lesson_date).
7
482.ЧДТУ.52179-01 13 01
schedule_materials
 Призначення: Зберігання навчальних матеріалів, пов'язаних із
конкретним заняттям у розкладі.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o schedule_entry_id (INTEGER, Not Null, Foreign Key ->
schedules.id, ON DELETE CASCADE, Index:
ix_schedule_materials_schedule_entry_id)
o uploader_id (INTEGER, Not Null, Foreign Key -> users.id, ON
DELETE CASCADE, Index: ix_schedule_materials_uploader_id)
o created_at (TIMESTAMP, Not Null, Default: now())
o description (TEXT, Nullable)
o title (VARCHAR(255), Not Null)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
schedule_material_attachments
 Призначення: Зберігання метаданих файлів, прикріплених до
навчальних матеріалів заняття.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o material_id (INTEGER, Not Null, Foreign Key ->
schedule_materials.id, ON DELETE CASCADE, Index:
ix_schedule_material_attachments_material_id)
o uploader_id (INTEGER, Nullable, Foreign Key -> users.id, ON
DELETE SET NULL, Index:
ix_schedule_material_attachments_uploader_id)
o filename (VARCHAR, Not Null)
o filepath (VARCHAR, Not Null, Unique)
o filesize (BIGINT, Nullable)
8
482.ЧДТУ.52179-01 13 01
o mimetype (VARCHAR, Nullable)
o uploaded_at (TIMESTAMP, Not Null, Default: now())
assignments
 Призначення: Зберігання інформації про завдання (домашні роботи,
проекти).
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o schedule_entry_id (INTEGER, Not Null, Foreign Key ->
schedules.id, ON DELETE CASCADE, Index:
ix_assignments_schedule_entry_id)
o created_at (TIMESTAMP, Not Null, Default: now())
o description (TEXT, Nullable)
o due_date (TIMESTAMP, Nullable, Index: ix_assignments_due_date)
o title (VARCHAR(255), Not Null)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
assignment_attachments
 Призначення: Зберігання метаданих файлів, прикріплених до завдання
(наприклад, умови завдання).
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o assignment_id (INTEGER, Not Null, Foreign Key -> assignments.id,
ON DELETE CASCADE, Index:
ix_assignment_attachments_assignment_id)
o uploader_id (INTEGER, Nullable, Foreign Key -> users.id, ON
DELETE SET NULL, Index:
ix_assignment_attachments_uploader_id)
o filename (VARCHAR, Not Null)
o filepath (VARCHAR, Not Null, Unique)
9
482.ЧДТУ.52179-01 13 01
o filesize (BIGINT, Nullable)
o mimetype (VARCHAR, Nullable)
o uploaded_at (TIMESTAMP, Not Null, Default: now())
submissions
 Призначення: Зберігання робіт, поданих студентами на завдання.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o assignment_id (INTEGER, Not Null, Foreign Key -> assignments.id,
ON DELETE CASCADE, Index: ix_submissions_assignment_id)
o student_id (INTEGER, Not Null, Foreign Key -> users.id, ON
DELETE CASCADE, Index: ix_submissions_student_id)
o created_at (TIMESTAMP, Not Null, Default: now())
o grade (VARCHAR, Nullable)
o status (VARCHAR, Nullable) - Наприклад, 'submitted', 'graded',
'late'
o submitted_at (TIMESTAMP, Nullable, Index:
ix_submissions_submitted_at)
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
 Обмеження: UNIQUE constraint (assignment_id, student_id) (якщо
студент може подати роботу лише один раз).
submission_attachments
 Призначення: Зберігання метаданих файлів, прикріплених до поданої
роботи студента.
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o submission_id (INTEGER, Not Null, Foreign Key -> submissions.id,
ON DELETE CASCADE, Index:
ix_submission_attachments_submission_id)
10
482.ЧДТУ.52179-01 13 01
o uploader_id (INTEGER, Nullable, Foreign Key -> users.id, ON
DELETE SET NULL, Index:
ix_submission_attachments_uploader_id)
o filename (VARCHAR, Not Null)
o filepath (VARCHAR, Not Null, Unique)
o filesize (BIGINT, Nullable)
o mimetype (VARCHAR, Nullable)
o uploaded_at (TIMESTAMP, Not Null, Default: now())
submission_comments
 Призначення: Зберігання коментарів до поданої роботи (наприклад,
фідбек викладача).
 Колонки:
o id (INTEGER, Primary Key, Auto Increment, Index)
o submission_id (INTEGER, Not Null, Foreign Key -> submissions.id,
ON DELETE CASCADE, Index:
ix_submission_comments_submission_id)
o author_id (INTEGER, Not Null, Foreign Key -> users.id, ON
DELETE CASCADE, Index: ix_submission_comments_author_id)
o comment_text (TEXT, Not Null)
o created_at (TIMESTAMP, Not Null, Default: now())
o updated_at (TIMESTAMP, Not Null, Default: now(), On Update:
now())
alembic_version
 Призначення: Службова таблиця Alembic для відстеження версій
міграцій бази даних.
 Колонки:
o version_num (VARCHAR(32), Primary Key, Not Null)
Основні зв'язки (Відношення):
 User <-> Group:
11
482.ЧДТУ.52179-01 13 01
o Один User (студент) може належати до однієї Group (One-to-
Many з боку Group). Зв'язок через users.group_id.
o Один User (викладач) може викладати у багатьох Group, і одна
Group може мати багатьох викладачів (Many-to-Many). Зв'язок
через teacher_group_association.
 User <-> Subject:
o Один User (викладач) може бути автором (викладачем) багатьох
Subject. Один Subject має одного викладача (One-to-Many з боку
User). Зв'язок через subjects.teacher_id.
 User <->
Post/Comment/PostLike/PostAttachment/ScheduleMaterial/Assignment
/Submission/SubmissionComment/various_Attachments:
o Один User може створити багато Post, Comment,
ScheduleMaterial, Assignment (якщо викладач), Submission (якщо
студент), SubmissionComment, etc. Зв'язок через author_id,
uploader_id або student_id.
o Один User може "лайкнути" багато Post (і навпаки). Зв'язок через
post_likes.
 Group <-> Schedule:
o Одна Group має багато записів у Schedule. Один запис Schedule
належить одній Group (One-to-Many з боку Group). Зв'язок через
schedules.group_id.
 Subject <-> Schedule:
o Один Subject може бути у багатьох записах Schedule. Один запис
Schedule належить одному Subject (One-to-Many з боку Subject).
Зв'язок через schedules.subject_id.
 Post <-> Comment/PostLike/PostAttachment:
o Один Post може мати багато Comment, PostLike, PostAttachment
(One-to-Many з боку Post). Зв'язки через post_id.
12
482.ЧДТУ.52179-01 13 01
 Comment <-> Comment:
o Один Comment може бути відповіддю на інший Comment (One-
to-Many, рекурсивний зв'язок). Зв'язок через comments.parent_id.
 Schedule <-> ScheduleMaterial/Assignment:
o Один запис Schedule може мати багато ScheduleMaterial та
Assignment (One-to-Many з боку Schedule). Зв'язок через
schedule_entry_id.
 ScheduleMaterial <-> ScheduleMaterialAttachment:
o Один ScheduleMaterial може мати багато
ScheduleMaterialAttachment (One-to-Many). Зв'язок через
material_id.
 Assignment <-> AssignmentAttachment/Submission:
o Один Assignment може мати багато AssignmentAttachment та
Submission (One-to-Many). Зв'язок через assignment_id.
 Submission <-> SubmissionAttachment/SubmissionComment:
o Один Submission може мати багато SubmissionAttachment та
SubmissionComment (One-to-Many). Зв'язок через submission_id.
ДОДАТОК Г
Вебзастосунок для обміну інформацією та організації роботи
студента
Інструкція системного програміста
482.ЧДТУ.52179-01 32 01
Листів 2
Розробник: _______________ Сергій ДОННЕР
Черкаси 2025
2
482.ЧДТУ.52179-01 32 01
РОЗГОРТАННЯ ПРОЕКТУ
Робота та тестування функціоналу проводилося переважно на
локальній машині перед розгортанням оновлень на сервері. Фінальна версія
додатку розгорнута на хмарній платформі Heroku з використанням бази
даних
PostgreSQL, що надається Heroku як сервіс.
Локальний запуск (для розробки та тестування):
 Отримання репозиторію
 Створення віртуального середовища: python -m venv venv та
venv\Scripts\activate для Windows.
 Встановлення залежностей: pip install -r requirements.txt.
 Налаштування середовища: Створити файл .env в корені проекту.
Вказати SECRET_KEY та DATABASE_URL для локальної бази даних
PostgreSQL (попередньо створеної). Приклад:
DATABASE_URL=postgresql+psycopg2://user:password@localhost:5432/s
tudhub_local_db.
 Налаштування бази даних: Переконатись, що локальний сервер PostgreSQL
запущено.
 Застосування міграцій: Запустити команду alembic upgrade head для
створення або оновлення структури локальної бази даних відповідно до
моделей SQLAlchemy.
 Запуск додатку: Використовувати ASGI-сервер Uvicorn: uvicorn app.main:app
--reload.
3
482.ЧДТУ.52179-01 32 01
Розгортання на Heroku:
 Підготовка: Переконатись, що в проекті є файли requirements.txt
(згенерований pip freeze > requirements.txt) та Procfile (з командою
запуску веб-сервера, напр., web: uvicorn app.main:app --host=0.0.0.0--
port=$PORT).
 Створення додатку на Heroku: Через веб-інтерфейс Heroku або за допомогою
Heroku CLI (heroku create <app-name>).
 Налаштування бази даних: Додати аддон Heroku Postgres до додатку (heroku
addons:create heroku-postgresql:hobby-dev). Heroku автоматично створить базу
даних та пропише її URL у змінну середовища DATABASE_URL додатку.
 Налаштування інших змінних середовища: Встановити змінну SECRET_KEY
в налаштуваннях додатку на Heroku (heroku config:set
SECRET_KEY='your_strong_secret_key').
 Підключення до GitHub (рекомендований спосіб): В налаштуваннях Heroku
додатку (розділ "Deploy") підключити репозиторій GitHub та налаштувати
автоматичне або ручне розгортання з гілки main.
 Розгортання: Запустити розгортання вручну або дочекатись бавтоматичного
після push у відповідну гілку GitHub. Heroku автоматично встановить
залежності з requirements.txt, виконає міграції бази даних (якщо налаштовано
в Procfile або через release phase) та бзапустить веб-процес згідно з Procfile.
 Доступ: Розгорнутий додаток буде доступний за адресою наданою heroku або
власним доменом(в разі якщо його прив’язали).
ДОДАТОК Д
Вебзастосунок для обміну інформацією та організації роботи
студента
Інструкція користувача
482.ЧДТУ.52179-01 34 01
Листів 9
Розробник: _______________ Сергій ДОННЕР
Черкаси 2025
2
482.ЧДТУ.52179-01 34 01
ДЕМОНСТРАЦІЯ ІНТЕРФЕЙСУ КОРИСТУВАЧІВ
Рисунок Д.1 – Головна сторінка
Рисунок Д.2 – Сторінка реєстрації
3
482.ЧДТУ.52179-01 34 01
Рисунок Д.3 – Сторінка логіну
Після авторизації відкривається сторінка профілю(див. нижче)
Рисунок Д.4 – Сторінка профілю
4
482.ЧДТУ.52179-01 34 01
В хедері доступні такі кнопки: профіль, розклад, публікації та панель
керування(в разі логіну з роллю адміністратора). При переході на сторінку
розкладу можна обрати дату для перегляду розкладу. Слот це умовне
позначення номеру пари (за номером слоту закріплений час відповідно до
графіку занять з сайту ЧДТУ, напр. 1 слот - 1 пара - 08:30 - 09:50). В свою
чергу викладачу доступне додавання занять(лише для груп які за ним
закріплені), студентам лише перегляд(див. нижче)
Рисунок Д.5 – Сторінка розкладу
Сторінка публікацій реалізована наступним чином:
Публікацію може створити будь-який користувач, сортування за
замовчуванням відбувається за останнім оновленням публікації (якщо
публікація щойно створена – вона зверху списку, якщо в публікацію додано
коментар – вона зверху списку), також сортування доступне за кількістю
лайків та коментарів(див. нижче).
5
482.ЧДТУ.52179-01 34 01
Рисунок Д.6 – Сторінка публікацій
При натисканні на кнопку створення публікації відкривається сторінка
з полями для введення назви публікації, вмісту та поле типу drag and drop для
додавання вкладень в публікації. Вміст підтримує форматування Markdown.
Рисунок Д.7 – Сторінка створення публікації
6
482.ЧДТУ.52179-01 34 01
Якщо ж ми відкриємо публікацію – користувачу доступний перегляд
публікації, додавання коментаря та лайку публікації, редагування власних
коментарів, або ж вмісту публікації якщо користувач є автором того чи
іншого (див. нижче)
Рисунок Д.8 – Сторінка перегляду публікації
Рисунок Д.9 – Додавання нового заняття
7
482.ЧДТУ.52179-01 34 01
Рисунок Д.10 – Перегляд заняття з роллю викладача
Рисунок Д.11 – Створення завдання до заняття
8
482.ЧДТУ.52179-01 34 01
Рисунок Д.12 – Перегляд та здача завдання в ролі студента
Рисунок Д.13 – Перегляд та здача завдання в ролі студента
9
482.ЧДТУ.52179-01 34 01
Рисунок Д.14 – Вікно оцінювання та обговорення роботи студента в ролі
викладача
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Положення про організацію навчального процесу в Черкаському
державному технологічному університеті. Черкаси 2022.
2. Положення про організацію контролю та оцінювання якості навчання
здобувачів вищої освіти Черкаського державного технологічного
університету. Черкаси 2022.
3. Положення про екзаменаційну комісію. Черкаси 2019.
4. ДСТУ 3008:2015 Звіти у сфері науки i техніки Структура i правила
оформлення.
5. ДСТУ 3582:2013 Інформація та документація. Скорочення слів в
українській мові в бібліографічному описі. Загальні вимоги та правила.
6. ДСТУ ГОСТ 7.1:2006 Бібліографічний запис. Бібліографічний опис.
Загальні вимоги та правила складання.
7. FastAPI Documentation. [Електронний ресурс]. – Режим доступу:
https://fastapi.tiangolo.com/ (дата звернення: 20.03.2025).
8. SQLAlchemy Documentation. [Електронний ресурс]. – Режим доступу:
https://www.sqlalchemy.org/ (дата звернення: 25.03.2025).
9. Alembic Documentation. [Електронний ресурс]. – Режим доступу:
https://alembic.sqlalchemy.org/ (дата звернення: 28.03.2025).
10.Pydantic Documentation. [Електронний ресурс]. – Режим доступу:
https://docs.pydantic.dev/ (дата звернення: 29.03.2025).
11.PostgreSQL Documentation. [Електронний ресурс]. – Режим доступу:
https://www.postgresql.org/docs/ (дата звернення: 20.03.2025).
12.Mozilla Developer Network (MDN Web Docs). [Електронний ресурс]. –
Режим доступу: https://developer.mozilla.org/ (Матеріали по HTML, CSS,
JavaScript, Fetch API). (дата звернення: 20.04.2025).
Арк.
ЧДТУ.252179.003 ПЗ 103
Змн. Арк. № докум. Підпис Дата
13.Ramalho L. Fluent Python: Clear, Concise, and Effective Programming. 2nd
Edition. – O'Reilly Media, 2022. – 984 p. ISBN 978-1492056355.
14.Grinberg M. Flask Web Development: Developing Web Applications with
Python. 2nd Edition. – O'Reilly Media, 2018. – 360 p. ISBN 978-1491991732.
15.Fielding R.T. Architectural Styles and the Design of Network-based Software
Architectures : Doctoral dissertation. – University of California, Irvine, 2000.
[Електронний ресурс]. – Режим доступу:
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (дата звернення:
24.03.2025).
16.JWT Introduction (jwt.io). [Електронний ресурс]. – Режим доступу:
https://jwt.io/introduction (дата звернення: 29.03.2025).
17.OWASP REST Security Cheat Sheet. [Електронний ресурс]. – Режим доступу:
https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.ht
ml (дата звернення: 10.04.2025).
18.ShowdownJS Documentation. [Електронний ресурс]. – Режим доступу:
https://github.com/showdownjs/showdown (дата звернення: 21.04.2025).
19.DOMPurify Documentation. [Електронний ресурс]. – Режим доступу:
https://github.com/cure53/DOMPurify (дата звернення: 21.04.2025).
20.OAuth 2.0 Authorization Framework (RFC 6749). [Електронний ресурс]. –
Режим доступу: https://datatracker.ietf.org/doc/html/rfc6749 (дата звернення:
29.03.2025).
Арк.
ЧДТУ.252179.003 ПЗ 104
Змн. Арк. № докум. Підпис Дата
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
