I have a a set of end to end tests that run on our app, and need to run against development, staging and production environments. The staging env is what is causing the issue.

The problem:

The staging server has basic auth, and links to images on a different server, also with basic auth. To elaborate: if you load the site (staging.oursite.com/page) there will be a basic auth prompt before anything loads, then after you enter creds and the page starts loading, another basic auth prompt when loading images from the image server. I can bypass the first basic auth prompt by navigating to user:[email protected]/page but it still pops the second basic auth prompt from the image server. This of course blocks the tests from proceeding.

Is there a good way around this? (besides somehow magically convincing my devs that it's both unnecessary and blocking me).

Our stack: webdriver.io (node.js + gulp + mocha) & in-house selenium grid server + chrome

  • Are you using Windows and an Active Directory login?
    – kirbycope
    May 31, 2017 at 23:47
  • Windows on a selenium grid box only (Eventually there should be more of these, but we have just the one for now).
    – Nat Bowman
    Jun 1, 2017 at 14:55

2 Answers 2


If you are using Windows + Active Directory, you can configure your internet settings to automatically respond to authentication requests using your AD credentials.

The following browser instructions are for Microsoft Internet Explorer and Google Chrome. Note that Chrome inherits its settings from IE's Local Intranet Zone. Even if this user is never planning to log in with IE, the following modifications must be made to ensure pass through on Chrome. Source

  1. Start the Internet Explorer browser
  2. Select Tools, Internet Options
  3. Click on Security Tab
  4. Click on Local Intranet Zone so that it is highlighted
  5. Click on Sites then click on Advanced.
  6. Type in the local Intranet Site (http://ipaddressofserver) and click on the ADD button

The following browser instructions are for Firefox

  1. Start Firefox. In the address bar type About:Config
  2. Once past the agreement prompt, type NTLM into the filter box
  3. Double click on network.automatic-ntlm-auth.trusted-uris entry

    1. Note: Environments limited to Kerberos authentication and do not accept NTLM authentication will need to adjust the network.negotiate-auth.delegation-uris, as well.
  4. Type in the local Intranet Site (http://ipaddressofserver) and click on the OK button


I ended up customizing a modify headers extension for chrome (https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj?hl=en) so it loads a set of header rules for my environment by default, stripped out the unneeded functionality.

When I start chromeDriver, I load that extension to load from my local repo using (--load-extension=${extensionDirFullPath}).
One roadblock I found was I have to
1. load the extension page (using chrome-extension:://${extensionID}/page).
2. Load another web page (I just use google).

Part of this is just waiting for the extension to load fully, but a wait (even a long one) is not sufficient to ensure that the extension loads and is used. strange stuff.

Also, because I'm loading the extension from a local folder rather than the chrome store, it loads with a different id on my grid node machine than from my local, and different again on my co-workers local. So in my BeforeAllTests, I threw this in:

let extFrame = browser.element('div#extensions iframe');
let extFrameID = extFrame.value;
extensionID = browser.element(`//div[@class='extension-details']//h2[text()='${extensionName}']/../../div[@class='developer-extras']/div/span[@class='extension-id']`).getText();

To get the id of the extension dynamically.
This is roughly the beforeSuite code to load the extension page and google:


When I get around to Firefox, it looks like there are several Modify Headers add-ons, which combined with using its own profile should work, with less code than this chrome solution.

Welp, I found a solution that works, but feels ugly and smells like bad code:
Each new browser session (depending on whether you are using a new session per suite or per test or whatever):
-Load a resource from the image server using the basic auth in the before Suite/Test/Whatever method.
-Load your base URL and proceed running the test/suite/whatever like before.

it works, but is kind of ugly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.