Accounts API (без GraphQL)
Документ описує REST-компоненти застосунку accounts: моделі, серіалізатори, utils,
ендпоїнти авторизації та сценарії роботи з JWT у сесії. GraphQL-шар навмисно пропущено.
ser_accounts_docs.md. Тут наведено лише
REST і допоміжні сервіси, які використовуються для класичної автентифікації акаунтів.
1. Архітектура apps.accounts
Моделі
UserProfile, StatusOnWork, Invite.
REST-шар
Views у views/auth.py, серіалізатори в serializers/auth.py, urls у accounts/urls.py.
Auth utils
SessionJWTAuthentication зберігає JWT у Django session і перезапускає access за refresh.
2. Моделі
UserProfile
- Розширює
AbstractUser, але використовуєemailякUSERNAME_FIELD. - Зберігає персональні дані (телефон, tg_username, адреса), стан працевлаштування, посилання на компанію, керівників, реквізити.
- Поля
first_sale,paidдозволяють позначити бізнес-статуси. leader(ManyToMany self) для побудови ієрархії.- Метод
save()автогенеруєusernameтаslugчерезgenerate_unique_value.
StatusOnWork
Проста довідникова таблиця зі статусами (Active, On Leave...). Використовується для UserProfile.status.
Invite
- Зв'язує
UserProfileзcompany.Company,roles.CompanyRole,roles.PositionInRole. - Використовується для керування запрошеннями до компанії.
3. Серіалізатори
- UserProfileSerializer — створює користувача, виконує валідацію пароля через
validate_passwordі виставляєwrite_only. - LoginSerializer — email+password.
- RequestPasswordResetSerializer / ResetPasswordSerializer — для ініціації та підтвердження відновлення доступу.
4. Auth utils
accounts/utils/CustomAuthJWT.py містить SessionJWTAuthentication:
- Читає
access_tokenіrefresh_tokenізrequest.session. - Перевіряє access через
rest_framework_simplejwt. Якщо протермінувався, генерує новий access із refresh, зберігає його в сесії. - Повертає користувача як
SimpleLazyObject, тож інші APIView можуть працювати як зі стандартним DRF auth.
Цей механізм дозволяє підтримувати веб-сесії з JWT, не передаючи токен у кожному запиті.
5. REST Views
RegisterView
- POST
/accounts/register/. - Приймає ім'я, email, пароль. Повертає створений профіль.
CheckRegistrationDataView
- POST
/accounts/check-password/. - Перевіряє email/пароль на валідність без створення акаунту.
LoginView
- POST
/accounts/login/. - Аутентифікація через
authenticate(email, password). - При успіху: генерує пару токенів
RefreshToken.for_user, зберігає їх у сесіїrequest.session, повертаєsessionid+ профіль.
LogoutView
- POST
/accounts/logout/(вимагаєIsAuthenticated). - Прибирає токени з сесії, викликає
logout(request).
Password reset
- RequestPasswordResetView — POST
/accounts/request-reset/: зберігає {email, token} у кеші (1 година) під ключемpassword_reset:email. - ResetPasswordView — POST
/accounts/reset-password/: перевіряє токен у кеші, змінює пароль, видаляє ключ.
6. URL-конфігурація
| Endpoint | Метод | Опис |
|---|---|---|
/accounts/register/ |
POST | Створення користувача через RegisterView. |
/accounts/login/ |
POST | Вхід, збереження JWT у сесії. |
/accounts/logout/ |
POST | Вихід, очищення сесії. |
/accounts/check-password/ |
POST | Валідація реєстраційних даних. |
/accounts/request-reset/ |
POST | Ініціація відновлення пароля. |
/accounts/reset-password/ |
POST | Зміна пароля після перевірки токена. |
/accounts/token/ |
POST | Стандартний TokenObtainPairView (для сервісів без сесій). |
/accounts/token/refresh/ |
POST | Оновлення JWT через DRF SimpleJWT. |
GraphQL endpoint /accounts/graphql/ тут не розглядається.
7. Приклади запитів
// Реєстрація
POST /accounts/register/
{"email": "demo@example.com", "password": "StrongPass1!", "first_name": "Demo", "last_name": "User"}
// Логін
POST /accounts/login/
{"email": "demo@example.com", "password": "StrongPass1!"}
// Перевірка перед реєстрацією
POST /accounts/check-password/
{"email": "demo@example.com", "password": "StrongPass1!"}
// Запит на відновлення
POST /accounts/request-reset/
{"email": "demo@example.com", "token": "123456"}
// Підтвердження відновлення
POST /accounts/reset-password/
{"email": "demo@example.com", "token": "123456", "new_password": "NewStrong1!"}
8. Типові сценарії
SPA + Cookies
Фронтенд виконує /login/, отримує sessionid cookie. Подальші запити йдуть із сесійною автентифікацією, а SessionJWTAuthentication забезпечує доступ до користувача.
Backend-to-backend
Можна використовувати стандартні ендпоїнти /token/ і /token/refresh/, оминаючи сесію.
Політика паролів
CheckRegistrationDataView дає миттєвий фідбек користувачу щодо email/пароля до створення акаунту.