3

I'm working on a CLI with OCLIF. In one of the commands, I need to simulate a couple of clicks on a web page (using the WebdriverIO framework for that). Before you're able to reach the desired page, there is a redirect to a page with a login prompt. When I use WebdriverIO methods related to alerts such as browser.getAlertText(), browser.sendAlertText() or browser.acceptAlert, I always get the error no such alert.

As an alternative, I tried to get the URL when I am on the page that shows the login prompt. With the URL, I wanted to do something like browser.url(https://<username>:<password>@<url>) to circumvent the prompt. However, browser.url() returns chrome-error://chromewebdata/ as URL when I'm on that page. I guess because the focus is on the prompt and that doesn't have an URL. I also don't know the URL before I land on that page. When being redirected, a query string parameter containing a token is added to the URL that I need.

A screenshot of the prompt:

prompt

Is it possible to handle this scenario with WebdriverIO? And if so, how?

Kaj Nelissen
  • 915
  • 10
  • 29

1 Answers1

1

You are on the right track, probably there are some fine-tunings that you need to address to get it working.

First off, regarding the chrome-error://chromewebdata errors, quoting Chrome DOCs:

If you see errors with a location like chrome-error://chromewebdata/ in the error stack, these errors are not from the extension or from your app - they are usually a sign that Chrome was not able to load your app.

When you see these errors, first check whether Chrome was able to load your app. Does Chrome say "This site can't be reached" or something similar? You must start your own server to run your app. Double-check that your server is running, and that the url and port are configured correctly.

A lot of words that sum up to: Chrome couldn't load the URL you used inside the browser.url() command.

I tried myself on The Internet - Basic Auth page. It worked like a charm.

  1. URL without basic auth credentials:

enter image description here

  1. URL WITH basic auth credentials:

enter image description here

  1. Code used:
  it('Bypass HTTP basic auth', () => {
    browser.url('https://admin:admin@the-internet.herokuapp.com/basic_auth');
    browser.waitForReadyState('complete');
    const banner = $('div.example p').getText().trim();
    expect(banner).to.equal('Congratulations! You must have the proper credentials.');
  });

What I'd do is manually go through each step, trying to emulate the same flow in the script you're using. From history I can tell you, I dealt with some HTTP web-apps that required a refresh after issuing the basic auth browser.url() call.


Another way to tackle this is to make use of some custom browser profiles (Firefox | Chrome) . I know I wrote a tutorial on it somewhere on SO, but I'm too lazy to find it. I reference a similar post here.

Short story, manually complete the basic auth flow (logging in with credentials) in an incognito window (as to isolate the configurations). Open chrome://version/ in another tab of that session and store the contents of the Profile Path. That folder in going to keep all your sessions & preserve cookies and other browser data.

Lastly, in your currentCapabilities, update the browser-specific options to start the sessions with a custom profile, via the '--user-data-dir=/path/to/your/custom/profile. It should look something like this:

'goog:chromeOptions': {
    args: [
        '--user-data-dir=/Users/iamdanchiv/Desktop/scoped_dir18256_17319',
    ],
}

Good luck!

iamdanchiv
  • 4,052
  • 4
  • 37
  • 42
  • 2
    Thanks for the reply! The problem was that I did not know the URL of the basic auth page up front because of several redirects happening. The example flow would be something like "click login button" -> redirect -> redirect -> redirect (some token gets added to the URL here) -> basic auth page. Your suggestion with the custom browser profile worked like a charm. I ended up using another solution however. I switched to the `devtools` protocol and turned on request intercepting before the redirects. At the point where the token gets added, I added the credentials in the URL to log in. – Kaj Nelissen Jun 15 '20 at 13:13
  • Nice work @KajNelissen! The devtools solutions sounds cleaner & more precise indeed, as tokens stored in custom profiles will eventually expire, or change altogether. – iamdanchiv Jun 16 '20 at 03:56
  • 1
    @KajNelissen i know this is old but could you share how you did it? – WalterM May 10 '21 at 01:44