Authentication | Playwright Python
Пояснює ізоляцію BrowserContext, повторне використання auth state та ризик витоку state-файлів.
На сторінці може бути різний контент — що робити? → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Playwright Isolation
Описує per-test BrowserContext і межу client-side isolation.
Що має вміти та знати мідл автоматизатор → Першоджерело ↗Playwright: Isolation
Межа BrowserContext і ризики cleanup-based isolation.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗Shared page послаблює default isolation
Ручне очищення cookies і local storage не дорівнює новому BrowserContext. Якщо reuse справді потрібен після вимірювання, fixture повинна мати явний contract стану й окрему regression check на leakage.
2. Pytest fixtures, playwright fixture, прараметризація тестів →storageState
Знімок стану BrowserContext, який охоплює cookies, localStorage та, за явними options актуального API, IndexedDB або virtual WebAuthn credentials.
На сторінці може бути різний контент — що робити? →Окремий context для Free-користувача
Fixture створює isolated BrowserContext із наперед підготовленим Free-state; Enterprise-state має бути окремою fixture або parameterized input із чіткою очікуваною роллю.
Тест стартує у визначеному Free-контексті без умовного розгалуження за випадковим UI-станом.
На сторінці може бути різний контент — що робити? →Channel, transport та ієрархія browser objects
[Дивитися з 04:40](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=280s). Перехід у реалізацію `click()` показує виклик на кшталт `channel.send(...)`: назва команди та її parameters передаються нижчому шару. Далі досліджується ієрархія об’єктів: `Browser` створює `BrowserContext`, context містить `Page`, а page працює з frames і locators. Python- і Java-клієнти не реалізують browser automation незалежно від основного Playwright driver. Вони формують команди та обмінюються повідомленнями з driver process через transport. Саме тому package містить platform-specific executable, а public API різних мов лишається концептуально подібним.
Завантаження `storage_state` у новий context
Самого запису state недостатньо: шлях треба передати в `browser.new_context(storage_state=...)`. Browser options збираються у dictionary, який доповнюється лише тоді, коли шлях передано і файл існує. Урок порівнює два JSON states після перемикання проєкту. Окрім `Company ID`, можуть змінюватися timestamps, analytics cookies і backend session, тому ручне припущення про «єдину різницю» треба перевіряти, а не приймати наперед.
Cookie helper для feature flags
Cookies корисні не лише для авторизації. Вони можуть увімкнути feature flag, направити автоматизований трафік на окремий backend або задати тестовий режим на спільному домені. Маніпуляцію варто сховати в короткий helper/decorator над `BrowserContext`: тест передає `name`, `value`, `domain` і `path`, а helper додає cookie. Domain має точно охоплювати потрібний host; після зміни зазвичай треба reload сторінки, щоб наступні запити та UI підхопили нове значення.
Shared page та очищення стану
Перші версії fixture щоразу відкривають нову вкладку або неправильно закривають page. Реалізацію уточнюють так, щоб параметризовані cases працювали на тій самій page, але перед новою ітерацією очищали cookies і local storage та поверталися у відомий початковий стан. Простого `localStorage.clear()` недостатньо для універсальної ізоляції: стан також може бути в session storage, IndexedDB, service workers або server-side session. Тому shared context має сенс лише тоді, коли перелік станів відомий і cleanup перевірений. Новий `BrowserContext` залишається надійнішою межею ізоляції.
Ієрархія Playwright і запуск test suites
У спрощеній моделі Playwright спочатку запускає browser process, потім створює ізольований `BrowserContext`, а в ньому — одну або кілька `Page`. Launch options стосуються процесу браузера, context options — сесії користувача, cookies, permissions та емуляції, а `Page` представляє вкладку й виконує дії зі сторінкою. Через `channel="chrome"` можна запустити встановлений branded Chrome замість bundled Chromium. Це потрібно, коли поведінка залежить від повного браузера або медіакодеків; для більшості перевірок швидшого bundled Chromium достатньо. Маркери дають змогу виконувати `smoke` і `regression` окремо. Практичний CI flow: спочатку короткий smoke suite перевіряє, що середовище придатне до тестування, і лише після нього запускається довша regression suite.
Playwright як тонкий клієнт і підсумкова модель
[Дивитися з 44:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2660s). Підсумкова ієрархія: створюється root `Playwright` instance, далі `Browser`, `BrowserContext` і `Page`; locators працюють у frame/page context. `ChannelOwner` та connection/transport пов’язують language client із driver process, а browser executable і потрібні artifacts перевіряються під час installation та startup. Для співбесіди достатньо пояснити модель без переказу кожного internal class: locator описує target; action збирає parameters; client надсилає command через transport; browser-side implementation виконує потрібні checks та повертає result; Playwright додає auto-waiting, locators, assertions, traces і reporting. Деталі protocol залежать від browser engine і версії Playwright.