A login wall is a routing problem, not a stop sign. "The app requires sign-in" is never by itself a reason to skip opening the app — there is almost always a sanctioned way in, and the person you are working for is usually already holding one.
When to use
- A dev server or deployed app redirects to a login page while you are verifying a change
- You are about to write "skipped browser verification because the app is behind auth"
- Asked to screenshot, click through, or smoke-test an authenticated product
The ladder — take the first rung that works
- Find the app's own dev door. Search before concluding anything:
.env.example, the README, and the auth module. Look for a dev-only bypass (DEV_*env vars, a mock session or test provider, seed users) and for production guards near the auth check (e.g.NODE_ENV !== "production"). Codebases that gate on auth usually built one. - Mint a temporary identity when you control the auth store. If the app reads users from a database you can write to (local dev, test env), insert a temp user — or point the bypass at a seeded one — verify, then remove what you added. Spoof identity only, never authorization: let the app's own role checks decide what the identity sees.
- Borrow the user's live session. When a browser that already holds the user's signed-in profile is available to you, use it for deployed or staging apps. Navigate and read; do not change account state, and treat everything on screen as their private data.
- Hand back exactly one human step. When only a real credential unlocks it (magic link, OAuth consent, MFA), do everything else first, then give the user the precise URL and the single action you need from them. Never enter their password or complete an auth challenge yourself.
Only when all four rungs fail may browser verification be replaced with code-level testing — and then name the rungs you tried and why each failed.
Rules
- Never type real credentials, and never create accounts on services you do not control. A temp row in the user's own local auth table is fine; a new account on a third-party service is not.
- Identity spoofing must stay inside a production guard. If you had to weaken an authorization check to get in, that is a finding to report, not a workaround to ship.
- Clean up what you minted: temp users, exported cookies, env edits that outlive the check.
- Verify with the role the change is for — and when a change touches privileged pages, verify those as the privileged role rather than stopping at "redirects to not-permitted, looks right".
Examples
Good: .env.example documents DEV_VIEWER_EMAIL as a magic-link bypass -> set it to a
seeded manager in .env.local, boot the dev server, screenshot the dashboard
rendering real data as that manager.
Bad: "Pages are behind roster sign-in, so I verified the SQL directly instead" — the
bypass was documented in .env.example, one search away.