Database Authorization
Фіксує поточний contract між JWT, PostgreSQL roles, grants і Row-Level Security.
Прихована складність бекенд-тестування → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Database authorization у PostgREST
PostgREST автентифікує request, перемикається на PostgreSQL role і залишає authorization базі даних. JWT claims, grants і Row-Level Security стають перевірюваними частинами API access control.
Прихована складність бекенд-тестування →Вибір способу авторизації
У Testomat.io API token не обов’язково є готовим bearer token для всіх запитів: його може бути потрібно обміняти на JWT через login endpoint. Урок демонструє, чому тип авторизації треба перевіряти за документацією та реальною відповіддю API. Секрет зберігається в environment variable, а не в коді. Постійне використання email/password додає зайвий запит і ширший секрет; token flow варто обирати лише якщо backend справді його підтримує.
Fixtures для авторизації і controllers
`pytest` fixtures виконують login, отримують JWT і передають його до `ProjectController` чи `SuiteController`. Якщо token вже збережено у scope fixture, нова авторизація не потрібна. Для створення suite спершу потрібен target project. Його можна підготувати окремою fixture або отримати в самому тесті через `ProjectController.get_all()`. Вибір залежить від того, чи це спільний precondition, чи важливий крок конкретного сценарію.
`BaseController`, headers, errors і logging
`BaseController` приймає base URL і JWT, формує спільні headers `Authorization` і `Content-Type: application/json`, виконує HTTP-запит і піднімає exception для неуспішного статусу. Методи `get`, `post` і `put` повторно використовують цю поведінку; `post` і `put` додатково приймають request body. Запити варто логувати, щоб під час падіння було видно method, endpoint і контекст виклику. Для `requests` таке logging додають явно; `HTTPX` має власний logging namespace, тому конкретна реалізація залежить від обраного client.
Мінімальний API client і pytest fixture
Клієнт містить лише потрібні операції: authentication і `get_projects`. У прикладі використано `httpx`, хоча для синхронного сценарію стандартний для проєкту HTTP-клієнт також достатній; не слід додавати dependency лише через згенерований AI-код. Авторизований client надається через pytest fixture. JWT кешується всередині instance, щоб кілька endpoint calls одного тестового lifecycle не повторювали login. Спочатку окремі API-тести перевіряють успішну авторизацію та непорожній список проєктів.