testing-web-authenticated-sessions

Captures and replays Playwright storageState sessions to test pages behind login walls.

Updated Apr 11, 2026
One-click install
npx skills add https://github.com/celikgo/webmobai --skill testing-web-authenticated-sessions-celikgo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-web-authenticated-sessions
Source: https://github.com/celikgo/webmobai/tree/main/.claude/skills/testing-web-authenticated-sessions
Command: npx skills add https://github.com/celikgo/webmobai --skill testing-web-authenticated-sessions-celikgo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Most of a real web application lives behind a login, but automated browser tests launch with a clean profile — no cookies, no localStorage — so they only ever see the login page. This Skill bridges that gap by capturing a logged-in session once into a Playwright storageState JSON file, then replaying it on every subsequent run so audits, crawls, and form tests can reach authenticated pages. ## Core Features & Use Cases - Session Capture (Mode A): Drive a headed browser through a real login — including manual MFA, CAPTCHA, or SSO steps completed by a human — verify the logged-in state with assertions, and save cookies plus localStorage to a session file via webmobai_save_storage_state. - Session Replay (Mode B): Seed fresh browsers from the saved file through MCP (storage_state_path), scenario JSON (storageState field), suite defaults, or CLI flags (--storage-state) for local and CI runs. - Login-Wall Detection & Expiry Handling: Recognize redirects to /login, blank authenticated shells, and 401/403 responses mid-run, preflight session files with webmobai-doctor, and re-capture expired sessions. - Use Case: A user asks to audit the accessibility of a dashboard behind Okta SSO. The Skill captures the session once with the human completing the hardware-key step, saves auth.json, then replays it so the accessibility audit runs against the real authenticated dashboard instead of the login page. ## Quick Start Ask the AI to save your login for https://app.example.com and then run the test suite against the logged-in dashboard using the saved session.

Frequently Asked Questions about testing-web-authenticated-sessions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a website that requires login with Playwright?▼

Log in once in a headed browser and save the session with webmobai_save_storage_state to a storageState JSON file. Then replay it on later runs via storage_state_path on launch, the scenario storageState field, or the --storage-state CLI flag, so tests start already authenticated.

How to handle MFA or SSO login in automated browser tests?▼

MFA, CAPTCHAs, and SSO consent screens cannot be automated, so capture the session in a headed browser where a human completes the second factor manually. After verifying the logged-in state with an assertion, save the session and replay it headlessly for subsequent runs.

Does Playwright storageState capture sessionStorage or IndexedDB?▼

No, storageState only captures cookies and localStorage; sessionStorage and IndexedDB are a Playwright limitation. An app that keeps its auth token in either cannot be replayed with this feature at all.

Why does my saved session fail with a redirect to /login in CI?▼

The session has likely expired, since nothing checks expiry at runtime and launch only verifies the file exists. Run webmobai-doctor --storage-state to check cookie expiry, then re-capture the session and push the refreshed file back to the CI secret store.

Is it safe to commit a Playwright storageState file to git?▼

No, the storageState file is a live credential containing session cookies and localStorage tokens in plaintext. Store it in a CI secret store, materialize it to disk at job runtime, and confirm your filename matches a .gitignore pattern before saving.

Why does --storage-state get ignored when running a suite?▼

In webmobai-suite, a scenario's own storageState field takes precedence over the --storage-state flag because the runner uses ??= assignment. If CI must control the session, leave storageState out of the scenario files entirely.