I’m working on a test automation project using Selenium WebDriver with Java and Chrome in headless mode. The web application I’m testing requires OTP authentication when accessing from a new device or browser instance.
System.setProperty("webdriver.chrome.driver", driverPath);
ChromeOptions options = new ChromeOptions();
options.setHeadless(true);
options.addArguments("--no-sandbox");
options.addArguments("--disable-dev-shm-usage");
WebDriver browser = new ChromeDriver(options);
browser.manage().window().maximize();
browser.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
browser.navigate().to("application-url");
Normally when using regular browsers like Chrome or Firefox, after completing OTP verification once on a machine, the application remembers the device and skips OTP prompts for future logins. However, with Chrome headless, it requests OTP verification every single time I run my automation script, even from the same computer.
I tried entering the OTP manually through console input during the first run, hoping it would save the verification status for subsequent runs, but that didn’t work. The headless Chrome seems to forget the OTP verification between sessions.
Is there a specific Chrome option or capability I need to configure to make headless Chrome behave like a regular browser and remember OTP verification? How can I prevent this repeated OTP prompt issue?
Chrome headless doesn’t save session data between runs. Each time WebDriver starts, it creates a new browser instance without storing cookies, local storage, or device fingerprints needed for device recognition. To fix this, you should set up a persistent user data directory by adding options.addArguments("--user-data-dir=/path/to/persistent/directory"); to your ChromeOptions. This allows Chrome to save all session data, cookies, and device info, maintaining them across runs. Ensure the directory exists and has appropriate write permissions. Additionally, consider using --disable-web-security in a controlled environment, as it can help bypass certain app security checks that interfere with headless detection. After implementing this, run your script once for OTP verification. On subsequent runs, the device trust should persist as Chrome will continue using the same session profile.
This issue is common with headless Chrome automation as it manages device fingerprints and sessions differently than standard browsers. To remedy this, it’s essential to implement a user data directory along with specific arguments that help disguise the headless Chrome instance. Include options like --disable-blink-features=AutomationControlled and --disable-extensions-file-access-check to your Chrome options. Additionally, assigning a constant user agent string can significantly improve device recognition stability. For more persistent solutions, consider building a session restoration mechanism; after your initial OTP verification, you can save cookies, local storage, and other session data to files that can be loaded for subsequent sessions. This approach can help the application believe it’s interacting with a recognized and trusted device. Lastly, maintain consistent browser properties like screen resolution, since some applications utilize advanced fingerprinting methods that can vary between headless sessions.
Chrome’s treating each headless session like a brand new device. Add --disable-features=VizDisplayCompositor and set a fixed --user-agent string so the app thinks it’s the same browser every time. Also don’t clear temp files between runs - you’ll wipe out your auth tokens.