Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
PostgREST автентифікує request, перемикається на PostgreSQL role і залишає authorization базі даних. JWT claims, grants і Row-Level Security стають перевірюваними частинами API access control.
Прихована складність бекенд-тестування →Спроєктуй negative tests для читання чужого row, підміни owner claim, вставки row поза дозволеним scope та запиту на erasure з legal-retention exception. Відокрем authentication evidence, database authorization і data-lifecycle decision.
Набір cases показує, який шар відхиляє кожну дію та який audit evidence потрібен.
Візьміть один feature flow і перевірте його через frontend, API та persistence boundaries. Зафіксуйте contract для time fields, кількість backend/provider calls, authorization states і system-level regression risks.
Короткий risk-based review із конкретними evidence та переліком перевірок, яких бракує.
Явний user permission, який application має отримати перед доступом до microphone або camera capture device. Permission state потрібно обробляти до початку recording workflow.
Корисні застосунки та їхнє призначення →Фіксує поточний contract між JWT, PostgreSQL roles, grants і Row-Level Security.
Прихована складність бекенд-тестування → Першоджерело ↗Authorization server видає/validates tokens і може масштабуватися окремо. Client — application, яка просить access; resource owner дає consent; resource server приймає access token і захищає API. Відео розрізняє user authorization і service-to-service access. Токен має представляти конкретного subject/client і не давати більше privileges, ніж потрібно.
Authorization request містить client ID, redirect URI, response type, scopes і state/PKCE parameters. Authorization server звіряє redirect з registered value, показує consent і повертає short-lived code. У current implementation redirect URI порівнюється exact, public client використовує PKCE `S256`, а transaction захищається від CSRF/mix-up. Самого client ID/redirect недостатньо для safe flow.
`RequestSpecification` зберігає спільні налаштування request: `baseUri`, `basePath`, logging та інші параметри. Окремі specifications можуть описувати різні domains або request types, наприклад multipart. У тесті синтаксичні `when` і `then` можна опусти, якщо після HTTP method одразу обробляється `Response`. Token передається в authorization header. У RestAssured є спеціалізовані auth methods, але в прикладі header задається явно. `Content-Type` описує формат request body, `Accept` — бажаний формат response. Неправильний або відсутній header може дати `4xx`, тому потрібний набір перевіряється експериментально.
[Дивитися з 06:10](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=370s). У реальній архітектурі browser звертається до API gateway, той перевіряє authentication та authorization, передає запит backend-сервісу, а backend отримує шаблон або ініціює відправлення через інший сервіс. Invite token має бути згенерований правильним компонентом, переданий без зміни й мати визначений TTL. Якщо контракт нечіткий, один сервіс може додати зайвий або захардкоджений token, після чого формально валідний request завершується невалідним invite. Перевірка лише зовнішньої специфікації endpoint не знаходить помилку в розподілі відповідальності між сервісами.
Access token короткоживучий; refresh token дає можливість отримати новий без повторної interactive authorization. Lifetime є server configuration, а не універсальні «дві години». На developer portal демонструється registration application/client, вибір scopes і redirect/callback URL. Client secret не можна вбудовувати в public mobile/browser client; там потрібен Authorization Code + PKCE.
User flow емулює дії людини і consent, service flow представляє machine client. Якщо test завжди бере admin/service token, він не перевіряє real user authorization boundaries. Потрібні positive/negative checks для scopes, audience, client type і resource access. Token exchange чи внутрішні service tokens не слід вигадувати за Network tab — їх contract має дати backend/security team.
[Дивитися з 24:35](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1475s). Простим можна вважати потік без зовнішніх інтеграцій і складних доменних правил, де запит напряму читає дозволені поля. Але навіть там можуть з'явитися GraphQL-подібні запити, складна authorization-фільтрація або performance-проблеми в database. Головний висновок: тестувальник має намалювати реальний dependency flow, з'ясувати, де виконуються authentication, authorization, billing, caching і error handling, а вже потім обирати рівні тестування та automation. Простота UI чи OpenAPI-контракту не є доказом простоти системи.
Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне `401`, бо потрібний header загубився між ними. API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.
Демо послідовно відтворює open login page, authenticate user, follow location/callback, extract authorization code і exchange it for tokens. Cookies оновлюються між кроками, тому shared state має бути explicit. Велика частина демо — live debugging невірного client/redirect та reverse engineering кроків. Практичний висновок: автоматизувати лише documented grant, а browser trace використовувати для пошуку discrepancy.
Щоб не передавати token в кожен controller method, `BaseController` зберігає його у field і додає authorization header, якщо значення не порожнє. Token-setting method повертає controller type, щоб його можна було викликати у fluent chain. Після цього resource methods більше не мають token parameter. Controller instances та login setup виносяться в `BaseTest`. Token отримується один раз у `@BeforeAll`, після чого ним конфігуруються `ProjectController` і `SuiteController`. Фінальний test залишає видимими лише сценарій, test data і assertions, а transport details залишаються у controllers.