Кукі, сесії та сховище браузера

Що таке cookie і навіщо вони потрібні?

Cookie — це маленький іменований шматок даних (імʼя=значення), який браузер зберігає й автоматично додає до наступних запитів на той самий сайт. Потрібні вони тому, що HTTP — протокол без памʼяті (stateless): кожен запит сервер отримує так, ніби бачить клієнта вперше, і в самому запиті немає нічого, що звʼязувало б його з попереднім. Кукі — будівельний матеріал «ілюзії памʼяті»: ви логінитесь один раз, а далі сервер упізнає вас за кукою в кожному запиті. Розмір однієї кукі невеликий — за RFC 6265 браузери мають підтримувати щонайменше 4096 байтів, тож у кукі кладуть ключі й прапорці, а не самі дані. Типовий вміст — ідентифікатор сесії, «запамʼятати мене», налаштування на кшталт теми.

Як cookie зʼявляється в браузері і як повертається на сервер?

Ставить кукі сервер — заголовком відповіді Set-Cookie, причому кожна кука — це окремий такий заголовок. Створити кукі може і JavaScript сторінки через document.cookie, але це вже дії самого застосунку, а не браузера. Далі браузер додає збережені кукі до кожного відповідного запиту одним заголовком Cookie — лише пари імʼя=значення, злиті через крапку з комою. Тут важлива асиметрія: атрибути (Path, Secure, HttpOnly тощо) їдуть тільки в Set-Cookie і назад не повертаються — вони потрібні браузеру, щоб вирішити, коли й куди кукі відправляти. Тому в перехопленому запиті атрибутів кукі не видно — дивитися їх треба у відповіді сервера або в DevTools.

Чим сесійна (session) cookie відрізняється від постійної (persistent)?

Сесійна кука не має ні Expires, ні Max-Age: вона живе, доки відкрита сесія браузера, і зникає після її завершення — типова роль для ідентифікатора сесії. Постійна кука має Expires або Max-Age, переживає перезапуск браузера й живе до вказаної дати — так реалізують «запамʼятати мене». Є застереження: функція відновлення вкладок («continue where you left off») у багатьох браузерах зберігає сесійні кукі між перезапусками, тож «закрив браузер — розлогінився» справджується не завжди. Для автотестів різниця принципова: постійні кукі надійно відновлюються зі збереженого storage state у новому контексті, а щодо сесійних (у файлі стану вони мають expires: -1) треба бути уважним — їх відновлення менш надійне.

Що таке серверна сесія і що насправді лежить у куці session_id?

У куці зазвичай лежить не стан користувача, а лише ключ до нього — ідентифікатор сесії (session id). Схема класична: після логіну сервер створює запис сесії у себе (в памʼяті, Redis, БД) з усім станом — хто ви, ролі, кошик — і віддає браузеру довгий випадковий рядок кукою Set-Cookie: session_id=.... На кожен наступний запит браузер надсилає цю кукі, сервер знаходить свій запис за ключем і «згадує» вас. Session id роблять довгим і випадковим (щоб не вгадати), позначають HttpOnly (щоб не вкрав XSS) і Secure (щоб не перехопили по HTTP). Імена таких кук часто видають стек: JSESSIONID — Java, PHPSESSID — PHP, connect.sid — Express, sessionid — Django. Альтернатива — токен (наприклад JWT), де стан зашитий у сам токен і сервер запис сесії не тримає.

Чим localStorage відрізняється від sessionStorage?

API в них однаковий (setItem/getItem, зберігають лише рядки), різниця — у часі життя й області видимості. localStorage живе постійно, доки його не стерли, і спільний для всіх вкладок одного origin (схема + хост + порт). sessionStorage живе, доки жива конкретна вкладка, і кожна вкладка має свій — нова вкладка чи новий контекст його не успадковують. Обсяг у обох — зазвичай близько 5 МБ на origin, і жодне з них ніколи не відправляється на сервер автоматично. Для автотестів привʼязка sessionStorage до вкладки — часта причина «зниклого» логіну: якщо застосунок тримає токен саме там, у новому контексті ви розлогінені, і storage state тут не допоможе — він sessionStorage не зберігає взагалі.

Чим cookie відрізняється від localStorage і що з цього автоматично відправляється на сервер?

Головний водорозділ — автовідправка: кука сама їде на сервер із кожним відповідним запитом у заголовку Cookie, а localStorage (як і sessionStorage та IndexedDB) не їде нікуди й ніколи — якщо дані мають дістатися сервера, застосунок явно кладе їх у тіло запиту або в заголовок на кшталт Authorization: Bearer .... Звідси й призначення: кукою тримають серверну сесію, у localStorage — те, що потрібне лише клієнтському JS (токени клієнта, чернетки, UI-налаштування). Інші відмінності: обсяг близько 4 КБ на кукі проти приблизно 5 МБ на origin; кука може бути захищена від JS через HttpOnly, а localStorage завжди доступний будь-якому скрипту на сторінці (ризик при XSS); час життя кукі керований атрибутами, localStorage живе, доки не стерли вручну. Для тестів це визначає стратегію авторизації: сесія на куці — переносимо кукі контексту, токен у сховищі — доведеться класти токен у сховище і, можливо, підправляти вихідний заголовок.

Що робить атрибут HttpOnly і як він впливає на автотести?

HttpOnly забороняє доступ до кукі з JavaScript: вона не видна в document.cookie, але браузер так само надсилає її на сервер. Мета — захистити токен сесії від крадіжки через XSS: навіть якщо на сторінці виконався чужий скрипт, кукі він не прочитає. Для автотестів наслідок прямий: HttpOnly-кукі не дістати ні через document.cookie, ні через page.evaluate — читати її треба на рівні контексту браузера, через API Playwright або Selenium (наприклад context.cookies()). Якщо тест «не бачить» кукі зі сторінки, хоча в DevTools вона є, — перше, що варто перевірити, це саме HttpOnly.

Навіщо атрибут Secure і яка з ним пастка на localhost?

Secure каже браузеру надсилати кукі лише через HTTPS — по HTTP вона не відправляється, що захищає від перехоплення в незашифрованому трафіку. Він обовʼязковий у парі з SameSite=None, інакше браузер кукі відкине. Пастка для тестувальника: браузери зазвичай трактують http://localhost як безпечний контекст, тож локально Secure-кукі працюють — а на іншому HTTP-хості без TLS та сама кука мовчки не поїде. Тому тест, зелений локально, може падати проти нелокального стенду без HTTPS, і виглядатиме це як «користувач розлогінений». Окремо варто памʼятати про префікси імен: кука на __Host- мусить бути Secure, поставлена з HTTPS, без Domain і з Path=/, а на __Secure- — просто Secure з HTTPS; якщо руками класти таку кукі в тесті з іншими атрибутами, браузер її мовчки не встановить.

Поясніть значення SameSite: Strict, Lax, None

SameSite керує тим, чи додається кука до запитів, які ініціює інший сайт, — це головний важіль проти CSRF (міжсайтова підробка запиту, cross-site request forgery). Strict — кука їде лише з того самого сайту: навіть перехід за посиланням з листа чи месенджера кукі не несе, тож перше відкриття може виглядати розлогіненим — і це очікувана поведінка, а не баг. Lax — те саме плюс верхньорівнева навігація безпечним методом (GET-перехід за посиланням), але не крос-сайт POST, не iframe, не картинки й не fetch з іншого сайту; у Chromium-браузерах це дефолт, коли атрибут не заданий. None — кука їде завжди, зокрема в міжсайтових запитах: потрібен для віджетів, iframe, SSO — і обовʼязково разом із Secure. Для AQA це критично у тестуванні SSO та платіжних редіректів: кука там має бути None; Secure, інакше сесія «губиться» на поверненні.

Кука має SameSite=None без Secure. Що побачить тестувальник?

Сучасний браузер таку кукі просто проігнорує — у тестах це виглядає як «сервер її ставить, а її немає». У відповіді заголовок Set-Cookie присутній, але в сховищі браузера кука не зʼявляється і в наступні запити не потрапляє. Це класична пастка формату «виглядає як баг бекенду, а насправді порушене правило браузера»: SameSite=None дозволений лише в парі з Secure. Діагностується швидко: порівняти Set-Cookie у відповіді з реальним вмістом сховища кукі — якщо кука «не долетіла», перевірити саме комбінацію атрибутів, а не логіку сервера.

Що означає «той самий сайт» для SameSite? Чи є піддомени same-site?

Same-site рахується за зареєстрованим доменом (eTLD+1), а не за повним хостом: запити між app.example.com і api.example.com — same-site, а між example.com і example.org — ні. Тому SameSite не заважає обміну кукі між власними піддоменами — за це відповідає атрибут Domain. Варто памʼятати й про різницю дефолтів: Lax для незаданого SameSite — поведінка саме Chromium-рушіїв (починаючи з Chrome 80), а Firefox і Safari цього дефолту не застосовують, там незадана кука поводиться майже без обмежень. Тож на дефолт покладатися не можна — SameSite задають явно на кожній куці. Плюс окремий пласт: Safari через ITP блокує сторонні кукі, а Firefox через Total Cookie Protection ізолює їх по «банках» на кожен сайт — незалежно від SameSite, тому крос-сайт сценарій, що працює в Chrome, може ламатися в іншому рушії.

Як атрибути Domain і Path впливають на відправку кукі та які типові баги з ними?

Domain і Path вирішують, на які запити браузер додасть кукі, — і помилка тут дає найпідступніший клас багів: кука фізично збережена, в DevTools видна, але на потрібний запит не летить. Без Domain кука host-only — прикріплена рівно до хоста, що її поставив: кука з app.example.com не поїде на example.com. З Domain=example.com вона їде і на домен, і на всі піддомени — а це вже ризик зайвого витоку сесії на стейджингові чи сторонні піддомени. Path обмежує шляхи: Path=/admin — і на /dashboard кука не піде; при цьому Path — не про безпеку, а лише про доставку, він легко обходиться. Типові сценарії в тестах: залогінилися на одному піддомені, перейшли на інший — «розлогінений»; або в addCookies вказали domain, що не збігається з реальним хостом, — кука ляже в стор, але браузер її не відправить. Правило діагностики: коли кука «є, але не працює», порівняйте її Domain/Path із хостом і шляхом запиту, який має її нести, — це швидше за будь-які здогади про згаслі сесії чи баги бекенду.

Що таке IndexedDB і коли її обирають замість localStorage?

IndexedDB — вбудована в браузер транзакційна обʼєктна база; її беруть, коли даних більше, ніж влазить у Web Storage, або потрібні структуровані записи з пошуком. Від localStorage вона відрізняється чотирма речами: зберігає не лише рядки, а структуровані обʼєкти й бінарні дані (Blob); API асинхронний і не блокує потік, на відміну від синхронного localStorage; обсяг значно більший (квоти рахуються від розміру диска й залежать від браузера); так само привʼязана до origin і так само не відправляється на сервер автоматично. Типові користувачі — офлайн-застосунки та PWA, які тримають там стан і кеш. Для AQA дві практичні речі: IndexedDB треба вміти чистити між тестами, і — пастка — за замовчуванням storage state у Playwright її не захоплює, тож якщо застосунок тримає сесію в IndexedDB, збережений стан вас не «залогінить»; від Playwright 1.51 є опція indexedDB: true для storageState(...), яка додає її у знімок.

Що таке storage state у Playwright, що в нього потрапляє, а що ні?

Storage state — знімок стану браузера, який зберігається у JSON-файл (context.storageState(...)) і піднімається в новому контексті через newContext зі storageState — так один раз пройдений логін перевикористовується без повторного проходу через UI. За замовчуванням туди потрапляють кукі й localStorage. Не потрапляють: sessionStorage — ніколи (його доводиться відновлювати вручну, наприклад init-скриптом через addInitScript), та IndexedDB — лише якщо явно передати indexedDB: true (Playwright 1.51+). Сесійні кукі у файлі мають expires: -1, і їх відновлення в новому контексті менш надійне, ніж постійних, — для стабільної авторизації краще спиратися на постійні кукі або токени. І про гігієну: файл містить живі секрети (session id, токени), тому в репозиторій його не комітять — генерують перед прогоном і тримають поза індексом.

Як організувати авторизацію в автотестах, щоб не проходити форму логіну в кожному тесті?

Проходити UI-логін у кожному тесті — повільно й крихко: будь-яка зміна сторінки входу валить усі тести підряд, тому логін виносять в один крок і перевикористовують результат. Перший патерн — «залогінитися раз»: у глобальному setup пройти UI-логін один раз на весь прогін, зберегти context.storageState({ path: 'auth.json' }), і далі кожен тест стартує вже залогіненим. Ще швидше — оминути UI взагалі: сходити API-запитом на ендпойнт логіну, дістати кукі чи токен і покласти їх у контекст через context.addCookies(...). У Selenium стан переносять через driver.manage().addCookie(...), але з важливим обмеженням: кукі можна додати лише для домену, на якому браузер уже перебуває, — тому спершу роблять get() на потрібний домен (нехай навіть на 404-сторінку), потім додають кукі, і лише потім ідуть углиб застосунку. Вибір між кукою і токеном визначається тим, де застосунок тримає сесію: куки переносяться контекстом, токен зі сховища доведеться класти в сховище й відтворювати заголовок.

Навіщо чистити стан між тестами і чому чистка на клієнті не гарантує ізоляцію?

Головна вимога до набору тестів — ізоляція: результат тесту не має залежати від того, що і в якому порядку виконувалося до нього, а кукі, localStorage і IndexedDB — спільна памʼять, яка легко протікає між тестами. Типові симптоми брудного стану: тести зелені поодинці, але червоніють у наборі (класична ознака залежності від порядку); тест логіну проходить, бо попередній уже залишив кукі сесії; тест розлогіну падає через раз, бо стартовий стан щоразу різний. У Playwright ізоляцію значною мірою дає модель контекстів — кожен тест отримує свіжий BrowserContext зі своїми кукі й сховищами; небезпека зʼявляється, коли стан шерять свідомо: той самий storage state, спільний акаунт, дані в БД. Тоді чистять явно: context.clearCookies() плюс localStorage.clear() і sessionStorage.clear() через page.evaluate. Але чистка на клієнті не прибирає серверний стан: якщо тест наплодив записів під спільним акаунтом, наступний їх побачить навіть з ідеально чистими кукі — ізоляція стану це і клієнт, і сервер.

Наступний тест бачить користувача розлогіненим. Як діагностувати?

Розлогінений вигляд означає рівно одне: на запит не поїхала валідна кука сесії або не пішов токен — далі питання лише «чому саме». Алгоритм завжди той самий: спершу подивитися, які кукі реально є в контексті (context.cookies()), потім — що реально пішло в заголовку Cookie проблемного запиту (перехопленням мережі). Якщо кукі немає взагалі — не підхопився storage state (контекст стартує без нього або файл порожній), або сесія жила в sessionStorage/IndexedDB, які у стан за замовчуванням не потрапляють, або кука була сесійною (expires: -1) і не пережила рестарт. Якщо кука у сторі є, але в запит не поїхала — майже завжди винні Domain, Path, Secure чи SameSite: звірити їх із хостом і шляхом запиту. Якщо кука і є, і поїхала — причина поза кукою: сесія згасла посеред прогону (логінитися ближче до тестів, оновлювати частіше за TTL) або спільний акаунт «вбили» паралельні воркери (ізолювати акаунти). Такий порядок перевірок дає діагноз за хвилини замість перебору здогадок.

Три кейси, де стан браузера вирішує, зелений тест чи флак: перевикористання логіну через storage state (і чому sessionStorage/IndexedDB туди не потрапляють), діагностика «наступний тест бачить користувача розлогіненим» через звірку кукі в сторі з реальним заголовком Cookie, і логін через API без UI з пасткою неправильного domain у addCookies. Скрізь — що дивитися і чому.

Кейс 1. Storage state: логін один раз, але не все переноситься

Проходити форму входу в кожному тесті повільно й крихко. Логін виносять в один прохід і зберігають знімок стану, а далі кожен контекст стартує вже залогіненим:

// global-setup: один прохід UI-логіну на весь прогін
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://app.example.com/login');
await page.fill('#email', process.env.USER_EMAIL);
await page.fill('#password', process.env.USER_PASSWORD);
await page.click('button[type=submit]');
await page.waitForURL('**/dashboard');
await context.storageState({ path: 'auth.json' });

Файл — звичайний JSON, який корисно читати очима, бо в ньому видно, що саме збереглося:

{
  "cookies": [
    { "name": "session_id", "value": "abc123def456",
      "domain": "app.example.com", "path": "/",
      "expires": 1767225600, "httpOnly": true,
      "secure": true, "sameSite": "Lax" }
  ],
  "origins": [
    { "origin": "https://app.example.com",
      "localStorage": [ { "name": "token", "value": "eyJhbGciOiJI..." } ] }
  ]
}

Що дивитися і чому:

• До знімка йдуть кукі й localStorage — і все. sessionStorage не потрапляє ніколи, IndexedDB — лише з indexedDB: true (Playwright 1.51+). Якщо застосунок тримає сесію саме там, «залогінений» стан не підхопиться, і новий контекст покаже розлогінений екран. Те, що не зберігається, відновлюють вручну — наприклад, sessionStorage через addInitScript на кожній сторінці.
• "expires": -1 — це сесійна кука. Її відновлення в новому контексті менш надійне, ніж постійної. Для стабільної авторизації спирайтеся на постійні кукі (remember me) або токен, а не на сесійну.
• Файл — живий секрет. У ньому справжній session id і токен, тож auth.json не комітять: генерують перед прогоном і тримають поза індексом.

Кейс 2. «Наступний тест бачить розлогіненим»: кука в сторі є, а в запит не поїхала

Найпідступніший клас багів: у DevTools кука видна, а застосунок поводиться так, ніби ви не авторизовані. Розлогінений вигляд означає рівно одне — на запит не поїхала валідна кука сесії. Алгоритм завжди той самий: звірити, які кукі реально є в контексті, з тим, що реально пішло в заголовку Cookie проблемного запиту.

import { test, expect } from '@playwright/test';

test('кука сесії реально їде на потрібний запит', async ({ page, context }) => {
  // 1) що лежить у сторі
  const stored = await context.cookies();
  const session = stored.find((c) => c.name === 'session_id');
  expect(session, 'session_id немає в контексті взагалі').toBeTruthy();

  // 2) що реально пішло в заголовку Cookie
  // важливо: синхронний req.headers() НЕ віддає cookie-заголовок —
  // читати треба асинхронним allHeaders()/headerValue()
  let sentCookie = '';
  page.on('request', async (req) => {
    if (req.url().includes('/api/me')) sentCookie = (await req.headerValue('cookie')) ?? '';
  });
  await page.goto('https://app.example.com/dashboard');

  // розбіжність «у сторі є / у запиті нема» = діагноз
  expect(sentCookie, 'кука у сторі є, а в запит не поїхала').toContain('session_id=');
});

Що дивитися і чому:

• Порожньо в сторі vs порожньо в запиті — це різні діагнози. Немає кукі в контексті взагалі → storage state не підхопився (перевір, що контекст стартує з storageState, а файл не порожній). Кука є, але в заголовок не потрапила → майже завжди Domain, Path, Secure або SameSite.
• Занадто вузький Domain/Path. Кука host-only на www.example.com не поїде на app.example.com; Path=/app не піде на /dashboard. Симптом ідентичний «розлогінений», хоча в DevTools кука на місці. Звірте domain/path кукі з хостом і шляхом того запиту, що має її нести.
• Сесія жила в sessionStorage/IndexedDB. Логін є, але після нового контексту зникає, і в кукі шукати марно — вона там і не була. Ознака: у storage state цих даних немає.
• Починайте саме зі звірки, а не з гіпотез. Розбіжність «є в сторі / немає в запиті» — швидша перевірка, ніж здогади про згаслі сесії чи баги бекенду.

Кейс 3. Логін через API без UI: пастка domain в addCookies і читання HttpOnly-кукі

Найшвидший логін оминає UI: сходити запитом на ендпойнт входу, дістати кукі й покласти в контекст. Але тут два місця, де воно тихо не працює.

import { test, expect } from '@playwright/test';

test('API-логін кладе кукі на правильний домен', async ({ context, request }) => {
  const res = await request.post('https://app.example.com/api/login', {
    data: { email: process.env.USER_EMAIL, password: process.env.USER_PASSWORD },
  });

  await context.addCookies([
    { name: 'session_id', value: extractSessionId(res),
      domain: 'app.example.com', path: '/',   // саме хост застосунку, не www і не .example.com
      httpOnly: true, secure: true, sameSite: 'Lax' },
  ]);

  const page = await context.newPage();
  await page.goto('https://app.example.com/dashboard');

  // HttpOnly-куку document.cookie НЕ побачить — це не баг, так задумано
  const viaJs = await page.evaluate(() => document.cookie);
  expect(viaJs).not.toContain('session_id=');

  // читати таку куку треба через API контексту
  const session = (await context.cookies()).find((c) => c.name === 'session_id');
  expect(session?.httpOnly).toBe(true);
});

Що дивитися і чому:

• domain в addCookies мусить збігатися з реальним хостом. Вкажете www.example.com замість app.example.com — кука ляже, але браузер її не відправить. Симптом ідентичний «розлогінений», хоча в сторі кука є. У Selenium додатковий нюанс: кукі можна класти лише для домену, на якому браузер уже перебуває, — тож спершу get() на домен, потім addCookie, і лише потім углиб застосунку.
• HttpOnly → тільки context.cookies(). Через document.cookie токен сесії не прочитається ніколи, бо HttpOnly розриває головний вектор XSS. Асерт httpOnly === true заразом фіксує, що атрибут безпеки на місці.
• SameSite не лишайте «за дефолтом». Chromium вважає куку без атрибута за Lax, а Firefox і Safari — ні (там вона поводиться ближче до None). Для SSO/платіжних редіректів кука має бути None; Secure, інакше на поверненні із зовнішнього сайту сесія «губиться». None без Secure браузер відкине — виглядає як «сервер її ставить, а її немає».
• Чистка document.cookie не прибере HttpOnly-куку. Для ізоляції між тестами стартуйте з чистого контексту або кличте context.clearCookies(); клієнтська чистка серверний стан теж не чіпає.

Cookie: механізм і атрибути

• Розумію, чому HTTP stateless і як cookie, серверні сесії та сховища будують ілюзію памʼяті поверх безпамʼятного протоколу.
• Знаю, що cookie ставить сервер заголовком Set-Cookie (кожна кука — окремий заголовок), а браузер повертає лише пари імʼя=значення, злиті в один заголовок Cookie; атрибути назад не їдуть.
• Можу пояснити, що робить кожен атрибут: Domain, Path, Expires/Max-Age, HttpOnly, Secure, SameSite — і чому помилка в атрибуті виглядає як «нічого не працює», хоча кука фізично є.
• Розумію різницю host-only vs Domain=example.com: без атрибута кука прикріплена рівно до хоста, із заданим доменом — їде і на нього, і на всі піддомени.
• Знаю, що Path — про доставку, а не безпеку, а HttpOnly-куку не дістати ні через document.cookie, ні через page.evaluate — тільки через API контексту браузера.
• Можу пояснити пастку Secure на localhost (часто «безпечний контекст», тож працює) та префікси імен __Host-/__Secure-, які браузер мовчки відкине за «неправильних» атрибутів.

SameSite та сторонні cookie

• Можу пояснити Strict / Lax / None і чому None обовʼязково разом із Secure (інакше «сервер її ставить, а її немає»).
• Знаю, що same-site рахується за зареєстрованим доменом (eTLD+1): app.example.com і api.example.com — same-site, а example.com і example.org — ні.
• Розумію, чому Lax-дефолт — це поведінка лише Chromium, тож не покладаюся на дефолт і задаю SameSite явно.
• Знаю, що Safari (ITP) блокує, а Firefox (Total Cookie Protection) ізолює сторонні кукі незалежно від SameSite — тож крос-сайт SSO «з Chrome» може ламатися в іншому рушії.

Сесії, токени і сховища браузера

• Розумію, чому cookie зазвичай містить не дані, а непрозорий session id, а стан лежить на сервері; знаю, чому session id роблять довгим, HttpOnly і Secure.
• Можу пояснити розвилку «серверна сесія в кукі» vs «токен (JWT) у сховищі + заголовок Authorization» і що вона змінює для тестів.
• Знаю різницю session cookie vs persistent cookie і пастку відновлення вкладок («закрив браузер → розлогінився» справджується не завжди).
• Можу пояснити localStorage vs sessionStorage vs cookie: обсяг, час життя, область (origin / вкладка), доступ із JS і головний водорозділ — автовідправка на сервер.
• Знаю, що автоматично на сервер летять лише відповідні кукі; localStorage, sessionStorage, IndexedDB не їдуть самі — застосунок кладе їх у тіло чи заголовок явно.
• Розумію, чим IndexedDB відрізняється (структуровані дані, асинхронний API, більший обсяг) і чому це пастка для storage state.

Стан в автотестах і діагностика

• Можу пояснити, що таке storage state, що в нього за замовчуванням потрапляє (кукі + localStorage), а що ні (sessionStorage — ніколи; IndexedDB — лише з indexedDB: true, Playwright 1.51+).
• Знаю патерни перевикористання сесії без UI-логіну: глобальний setup зі storageState та логін через API з addCookies; памʼятаю обмеження Selenium — кукі додають лише на домені, де браузер уже перебуває.
• Розумію, навіщо ізоляція й чистка стану між тестами, чому модель контекстів Playwright дає її «безкоштовно» і що клієнтська чистка не прибирає серверний стан.
• Можу діагностувати «наступний тест бачить користувача розлогіненим»: порівняти, які кукі реально є в контексті (context.cookies()) і що пішло в заголовку Cookie запиту; розбіжність майже завжди вказує на Domain, Path, Secure або SameSite.