WebUI.authenticate Fails on Linux (CentOS) in Jenkins with Chrome Options, Works on Windows

Bug Report
1

Title
WebUI.authenticate Fails on Linux (CentOS) in Jenkins with Chrome Options, Works on Windows

Summary
WebUI.authenticate() works as expected on Windows 11 with Chrome options (–incognito, --headless) for handling SSO authentication. However, the same configuration consistently fails when running in Jenkins on CentOS Linux 7.9. It seems the method does not adapt well to Linux environments.
Additionally, when authentication succeeds on Windows, the test still fails unless FailureHandling.OPTIONAL is set, even though navigation to the target URL is successful.

Steps to Reproduce

configuring Chrome options like:
options.addArguments(“–incognito”)
options.addArguments(“–headless”)
or just:
options.addArguments(“–incognito”)

Use Katalon built-in keyword:
WebUI.authenticate(driver.getCurrentUrl(), user, pwd, 10, FailureHandling.OPTIONAL)

Run the test locally on Windows 11 → Authentication works, navigation continues.
Run the same test in Jenkins on CentOS Linux 7.9 → Authentication fails every time.

Expected Results

WebUI.authenticate() should work consistently across Windows and Linux environments.
After successful authentication, the test should not fail even if FailureHandling.OPTIONAL is not set.

Actual Results

On Linux (CentOS) in Jenkins, WebUI.authenticate() fails to handle SSO authentication.
On Windows, authentication succeeds, but the test fails unless FailureHandling.OPTIONAL is specified.

Screenshots / Videos
(Attach screenshots of Jenkins console logs and Windows execution logs if possible)

Blocker?
Yes – This prevents running SSO-related tests in CI/CD on Linux.

Number of Affected Users
All users running Katalon tests with SSO authentication on Linux environments.

Operating System

Windows 11 (local)
CentOS Linux release 7.9.2009 (Jenkins)

Katalon Studio Version
Version 10.3.2-0cbb703d07

Chrome driver version: 142.0.7444.175

2 Likes
2

We are on it now, please stay tuned for our updates, our support team is currently checking on it.

3

Hi there,

Thanks for reporting this issue. To help diagnose the problem better, could you please share the error logs from your Jenkins console output? Specifically, any error messages or stack traces that appear when WebUI.authenticate() fails on CentOS would be really helpful.

In the meantime, I’d suggest trying to add these Chrome arguments to your configuration:

options.addArguments("--headless=new")
options.addArguments("--no-sandbox")
options.addArguments("--disable-dev-shm-usage")

These flags are often necessary for running Chrome in headless mode on Linux environments, especially in Jenkins/Docker containers:

  • --headless=new uses Chrome’s newer headless implementation

  • --no-sandbox is required when running as root or in containerized environments

  • --disable-dev-shm-usage prevents crashes due to limited shared memory in Docker/Jenkins

Let us know if this helps or if you’re still seeing the same authentication failures. The logs will help us narrow down whether it’s a Chrome driver issue, authentication dialog handling, or something else.

2 Likes
4
  1. Prefer URL-embedded basic auth where possible
    If the target truly uses HTTP Basic Auth (not SSO redirect), you can avoid WebUI.authenticate and do:
WebUI.openBrowser('')
WebUI.navigateToUrl("https://user:[email protected]/path")

This pattern is known to work more consistently across OSes than WebUI.authenticate in many cases.​
2. Avoid WebUI.authenticate for SSO; script the login page instead
For SSO / IdP-based auth (Okta, Azure AD, etc.), treat it as a normal web flow:

  • Navigate to the login URL.
  • Locate username, password, and submit elements with Test Objects.
  • Use WebUI.setText / WebUI.click / waits to complete the flow.
    This keeps behavior consistent between Windows and Linux and avoids browser-level dialogs altogether.​
  1. On Windows where WebUI.authenticate “succeeds but still fails”
  • The keyword may throw an exception even though the browser ends up authenticated, which is why using FailureHandling.OPTIONAL makes the test continue.​
  • If you must keep it, wrap it in try–catch and assert success based on the resulting page state, not the keyword result:
try {
    WebUI.authenticate(url, user, pwd, 10)
} catch (Exception ignored) {
    // proceed to check if the page is actually authenticated
}
WebUI.verifyElementPresent(findTestObject('Page/Home/AuthenticatedMarker'), 20)
  1. Double-check headless + Jenkins specifics
  • Confirm your Linux Chrome/ChromeDriver versions match those used on Windows as closely as possible.​
  • If SSO is tightly coupled to desktop environment (Kerberos/NTLM integrated auth), headless Linux sessions often cannot reproduce it; you may need:
    • Non-headless runs in CI (using Xvfb),
    • Or dedicated test credentials with explicit username/password pages instead of integrated auth.​

Recommendation

  • Treat WebUI.authenticate as unreliable for SSO and cross‑platform headless runs.
  • For CI on CentOS/Jenkins, replace it with:
    • URL-embedded basic auth when applicable, or
    • A scripted HTML login flow on the IdP/login page.
  • On Windows, if you leave WebUI.authenticate in place, guard it with FailureHandling.OPTIONAL or try–catch and assert based on post-login elements instead of relying on the keyword’s pass/fail alone
1 Like
5

Hi @jayson_jiang ,

Welcome to our community. Hope you enjoy the time here

Please let try workaround suggested by @Slowey and see if your issue can be resolved. Thank you

6

Hi Elly and @Slowey,
Thank you for the suggestion. I tried the workaround, but it didn’t resolve the issue.

7

Hello,

On Windows 11, debugging has consistently worked as expected.

However, when I run the Katalon project in our Jenkins Linux container, the execution gets stuck on the Microsoft sign‑in/authorize page. This occurs regardless of the browser version: the container’s built‑in Chrome 142.0.7444.175, as well as Chrome for Testing 141.0.7390.122 and 138.0.7204.100 (extracted from the project’s 7z archive to /opt/). The Chrome for Testing binaries under /opt/ have 0755 permissions set.

The page where it hangs has a URL similar to:

?response_type=id_token%20token

&client_id=xxx-xxx-xxx-xxx

&state=xxxxxxxxx

&redirect_uri=https://xxx.xx.xxx.com/xxx/xxx/authorization/

&scope=openid%20profile

&nonce=xxxxxxxxx

8

@nghi.phan @Slowey

Hello,

On Windows 11, debugging has consistently worked as expected.

However, when I run the Katalon project in our Jenkins Linux container, the execution gets stuck on the Microsoft sign‑in/authorize page. This occurs regardless of the browser version: the container’s built‑in Chrome 142.0.7444.175, as well as Chrome for Testing 141.0.7390.122 and 138.0.7204.100 (extracted from the project’s 7z archive to /opt/). The Chrome for Testing binaries under /opt/ have 0755 permissions set.

The page where it hangs has a URL similar to:

?response_type=id_token%20token

&client_id=xxx-xxx-xxx-xxx

&state=xxxxxxxxx

&redirect_uri=https://xxx.xx.xxx.com/xxx/xxx/authorization/

&scope=openid%20profile

&nonce=xxxxxxxxx

Could you please advise if there is a solution?

image
image675×434 37.5 KB

9

Hi @jayson_jiang

Since you have a Katalon license, please continue troubleshooting with us via our support portal where a support agent can help you faster.

We’ve created a ticket for you here:

Please log in with your account and continue communicating with us through the ticket.

Thank you!

1 Like
10

Can you work with your network team and see if there any restriction in place if you try from linux container. if required, try to whitelist the IPs/urls

11

Based on the Katalon documentation, I found critical information about WebUI.authenticate():

Key Finding from Official Documentation:
According to the Using autoIT for authentication in Katalon Studio guide:

“WebUI.authenticate keyword in Katalon Studio would work well on Firefox browser, but the function might not work on other browsers due to unknown reasons.”

This directly explains your issue. The WebUI.authenticate() method has known limitations with Chrome and is not reliably supported across different operating systems, particularly on Linux.

Root Cause

Confirmed Issue: Browser Compatibility Limitation

  • WebUI.authenticate() is primarily designed for Firefox and has unreliable behavior with Chrome
  • The method does not adapt well to different OS environments (Windows vs. Linux)
  • Chrome headless mode with --incognito and --headless flags on Linux compounds this issue due to:
    • Differences in how Chrome handles authentication dialogs in headless mode on Linux
    • Potential issues with the underlying authentication mechanism on CentOS 7.9
    • Chrome driver version compatibility (you’re using 142.0.7444.175)

Solutions

Solution 1: Use AutoIT for Cross-Platform Authentication (Recommended for Windows)

Source: Using autoIT for authentication in Katalon Studio

Note: AutoIT is Windows-only and won’t work on Linux/CentOS.

Steps:

  1. Install AutoIT from https://www.autoitscript.com/site/autoit/downloads/

  2. Create an AutoIT script to handle authentication:

    WinWaitActive("","Authentication Required","10")
WinFlash("", "Authentication Required",4,500)
If WinExists("","Authentication Required") Then
    Send("Username{TAB}")
    Send("Password{Enter}")
ElseIf WinExists("","Chrome Legacy Window") Then
    Send("Username{TAB}")
    Send("Password{Enter}")
ElseIf WinExists("","Windows Security") Then
    Send("Username{TAB}")
    Send("Password{Enter}")
EndIf

  3. Compile to .exe and call from your test:

    WebUI.openBrowser('')
autoit_prj = 'D:\\path\\to\\Authentication_Custom.exe'
Runtime.getRuntime().exec(autoit_prj)
Thread.sleep(3000)
WebUI.navigateToUrl('http://your-auth-url')

Solution 2: Manual Authentication Handling (Cross-Platform)

Source: Katalon Documentation best practices

For Linux/CentOS environments, implement manual authentication by:

  1. Remove Chrome headless mode for authentication tests:

    // Don't use --headless with --incognito for auth tests
options.addArguments("--incognito")
// Remove: options.addArguments("--headless")

  2. Manually handle authentication instead of using WebUI.authenticate():

    WebUI.openBrowser('')
WebUI.navigateToUrl('http://username:password@your-auth-url')
// Or use form-based login if available
WebUI.setText(findTestObject('username_field'), 'user')
WebUI.setText(findTestObject('password_field'), 'pwd')
WebUI.click(findTestObject('login_button'))

Solution 3: Use Firefox Instead of Chrome

Source: WebUI.authenticate Documentation

Since WebUI.authenticate() works reliably with Firefox:

// Switch to Firefox for authentication tests
WebUI.openBrowser('')
WebUI.authenticate('http://your-auth-url', 'username', 'password', 10, FailureHandling.OPTIONAL)

Firefox is more compatible with WebUI.authenticate() on both Windows and Linux.

Solution 4: Implement Custom Authentication Handler

For SSO authentication on Linux, create a custom keyword:

@Keyword
def handleSSO(String url, String username, String password) {
    WebUI.openBrowser('')
    WebUI.navigateToUrl(url)
    
    // Wait for auth dialog
    WebUI.waitForElementPresent(findTestObject('auth_username'), 10)
    
    // Enter credentials
    WebUI.setText(findTestObject('auth_username'), username)
    WebUI.setText(findTestObject('auth_password'), password)
    WebUI.click(findTestObject('auth_submit'))
    
    // Verify successful authentication
    WebUI.waitForElementPresent(findTestObject('post_auth_element'), 10)
}

Recommendations

  1. For Windows: Use AutoIT solution (Solution 1) for reliable authentication handling
  2. For Linux/CentOS: Use manual authentication (Solution 2) or Firefox (Solution 3)
  3. For CI/CD: Avoid --headless mode during authentication tests; use headless mode only for subsequent test steps
  4. Always use FailureHandling.OPTIONAL when calling WebUI.authenticate() to prevent test failure if the method doesn’t work as expected
  5. Consider upgrading Chrome driver to the latest stable version compatible with your Katalon Studio version
2 Likes