Chrome 59 and Basic Authentication with Selenium/Fluentlenium

Question

Chrome 59 has removed support for https://user:password@example.com URLs.

I have a test which was using this feature which has now broken, so I\'m trying to replace

Answer 1

One solution is to run a transparent proxy to inject the header with the required credentials.

But another and easier solution is to create a small extension to automatically set the credentials:

https://gist.github.com/florentbr/25246cd9337cebc07e2bbb0b9bf0de46

Answer 2

Over in https://bugs.chromium.org/p/chromium/issues/detail?id=435547#c33 you can see a mkwst saying there was a bug regarding basic auth credentials and same origin sites made it into stable.

If you use the "--disable-blink-features=BlockCredentialedSubresources" or go to a Chrome Canary build you may find that the original problem you were seeing is not happening any more...

Answer 3

Florent B. found a solution with the help of a chrome extension, that is added on the fly in the selenium test. The extenion handles the basic auth credentials, if requiered:

ChromeOptions options = new ChromeOptions();
options.addExtensions(new File("C:/path_to/credentials_extension.zip"));
driver = new RemoteWebDriver(new URL("http://127.0.0.1:9515"), options);

Chrome extension code: https://gist.github.com/florentbr/25246cd9337cebc07e2bbb0b9bf0de46
(just modify username and password in background.js and then zip the files background.js and manifest.json to credentials_extension.zip)

Found here: Selenium - Basic Authentication via url

Answer 4

I'm sure Florent B's solutions are viable, but for retro-fitting an old test, I found that zoonabar's solution posted to this duplicate question is easier to implement, takes considerably less code, and requires no special preparation of the test box. It also seems that it would be easier to follow for new developers looking at the code.

In short: visiting any URL with credentials before visiting the URL under test (without credentials) will cause the browser to remember the credentials.

goTo("http://user:password@localhost"); // Caches auth, but page itself is blocked
goTo("http://localhost"); // Uses cached auth, page renders fine
// Continue test as normal

This may feel like a vulnerability in the browser which will be patched, but I think this is unlikely; the restriction has been imposed to avoid phishing risks (where the username chosen looks like a domain, e.g. "http://google.com:long-token-here-which-makes-the-real-domain-disappear@example.com/"), and this workaround for setting credentials doesn't pose the same risk.

See zoonabar's answer