Authentication Cheat Sheet
Додає security boundary для MFA, authentication logging і test-only seams.
Юзер менеджмент та костилі з якими ви стикнетесь в житті → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
WebDriver BiDi
Current Selenium підтримує logging, network і script domains через bidirectional WebDriver APIs; різницю з Playwright коректніше описувати як integrated workflow та ergonomics.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Спроєктувати safe test contract
Відокремити application-flow, provider-integration і production-smoke tests.
Обрати official test key або non-production test mode.
Описати scope, secret storage, allowlist, rotation, logging і expiry.
Додати negative test, який підтверджує, що звичайний traffic не отримує bypass.
Threat-reviewed contract не містить hardcoded production bypass і має окрему перевірку provider integration.
Request/response logging і Allure
Request і response логуються так, щоб failure міг відтворити розробник. RestAssured filters дають central logging seam, а Allure integration може прикріпити HTTP exchange до test step. Логи можуть містити credentials, tokens і personal data. У production-like test environments потрібне masking/redaction; «логувати все» — лише діагностичний старт, а не безпечний дефолт.
Логування і витягування token з response
`log().all()` показує request і response, включно з form parameters; `prettyPrint()` дає компактніший вивід body. Повні headers потрібні лише тоді, коли діагностика вимагає більше, ніж response body. Щоб використати token в наступних requests, response переводиться в extract mode, а значення зчитується через JsonPath `getString`. Отриманий token зберігається у змінну для виклику projects API.
`RequestSpecification`, authorization і content negotiation
`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`, тому потрібний набір перевіряється експериментально.
RestAssured request і media types
RestAssured дає BDD-style `given`/`when`/`then`. У request configuration задаються base URI/path, headers, query/form parameters, body і logging; HTTP method запускає виклик, а response validation перевіряє result. `Content-Type` описує request body, `Accept` — бажаний response format. `415 Unsupported Media Type` і інші `4xx` часто свідчать про помилку request contract, тому headers перевіряються явно.
Custom RestAssured log filter і розбіжності даних
Для сталого логування request і response додається custom filter, який реалізує RestAssured `OrderedFilter`. Він логує request до виклику і response після нього, а також не намагається виводити порожнє body. Filter передається в base API configuration, тому всі controllers мають однакову діагностику. Лог показує розбіжності між create і list responses: наприклад, labels в одному response мають інше значення, а description не повертається так, як очікувалося. Частина помилок належить не DTO, а неідеальному API contract.