Playwright Two-factor Authentication
You set up playwright two factor authentication by generating time-based codes during your login flow. You can also save a signed-in browser state and reuse it across test runs. Most engineering teams store a shared secret key inside their test runner settings. Then the test script reads that secret key and types the six-digit code. Still, teams often grant broad admin roles to these automated test accounts. If a test secret leaks, an attacker gains full power over your system. How playwright
Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up playwright two factor authentication by generating time-based codes during your login flow. You can also save a signed-in browser state and reuse it across test runs. Most engineering teams store a shared secret key inside their test runner settings. Then the test script reads that secret key and types the six-digit code. Still, teams often grant broad admin roles to these automated test accounts. If a test secret leaks, an attacker gains full power over your system.
How playwright two factor authentication works in tests
Automated browser tests need a fast way to pass a second login step. Human users read a code from a phone app or a text message. A test runner cannot look at a physical phone screen during a build. Instead, teams use a time-based one-time password algorithm inside the test workflow. When you create the test user, the app gives you a setup key. You save this setup key in your continuous integration secret store.
During the test run, the script opens the login page and enters the username. Next, it enters the password and submits the form to trigger the prompt. A helper library reads the saved setup key and checks the current clock. It calculates the exact six-digit code for that specific thirty-second window. The browser script types this code into the input box and finishes logging in.
After the first login finishes, the runner saves the session cookies to a file. Later tests load this file so they do not need to log in again. This cuts down test time and avoids rate limits on the login page.
Choosing between code generation and session reuse
Teams usually pick one of three paths when testing protected web apps. The first path generates a fresh time-based code on every single test run. This tests the real login screen well, but it slows down large suites. Also, two parallel tests might try to use the exact same code at once. Many identity servers block a code after its first use to stop replay attacks.
The second path logs in once before the main test suite starts. It writes the browser storage state to a local disk file. Every worker process reads that file and starts already logged into the app. You still keep one dedicated test spec to check the login screen itself. The third path bypasses the user interface and requests a session token via API. This is fast, yet it skips testing the actual multi-factor screen in a browser.
Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native test login setups leave open
Storing a setup key in your test runner solves the browser login block. It proves that your automated script can log in as a specific test user. Still, login checks only decide who gets into the app or database. They do not inspect what individual queries or commands do after login finishes.
Test accounts often hold broad permissions so they can seed data and reset tables. Engineers also pull production-like data into staging databases to make tests realistic. Once the test script or a developer logs in, every query runs unchecked. A broken script can run a destructive delete command against shared staging tables. Also, query results can return real emails, phone numbers, or card numbers into build logs. Native login roles cannot mask sensitive fields in results or block single risky commands.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Should we turn off two-factor checks in staging environments?
Turning off extra login checks in staging creates a dangerous gap between environments. Bugs in the login flow will slip into production without warning. Keep the check active for a few login tests and reuse state elsewhere.
How do we stop parallel tests from reusing the same six-digit code?
Run a single setup step that logs in once and saves the browser state. Have your parallel test workers load that saved session file instead of logging in. If you must test login in parallel, give each worker a separate user account.
Why do time-based codes sometimes fail in continuous integration builds?
Time-based codes rely on the system clock matching the login server clock. If the build machine clock drifts by thirty seconds, the generated code fails. Sync the build server clock using network time protocol and retry on clock boundaries.