Host validation failing when using chromedriver in container

[Romaric Drigon]

Hello,

We are using chromium + chromedriver inside containers, in production, using Docker Swarm. Since chromedriver 92.0.4515.43  release, we are seeing errors in logs:

Starting ChromeDriver 92.0.4515.43 (8c61b7e2989f2990d42f859cac71319137787cce-refs/branch-heads/4515@{#306}) on port 4444 All remote connections are allowed. Use an allowlist instead! Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe. ChromeDriver was started successfully. [1626854389.203][SEVERE]: GetCanonicalHostName Error hostname: 323b53490eb5 [1626854389.204][SEVERE]: Unable find match for host: chrome:4444

I believe the issue is caused by "Make RequestIsSafeToServer more secure" patch, and I couldn't find any way around.
When using Docker Swarm (as many other container engines, I would guess), you use service names ("chrome", in our case) to communicate in between containers. Hostname ("323b53490eb5"  in my example) are handled internally by the engine, you can't use those (neither you can easily IPs). 

But then there will be a mismatch before incoming request "Host" and hostname as determined  by "GetCanonicalHostName", line 139 (it uses getaddrinfo() internally I believe, but I don't see how to make it handle Docker services / host mapping).

Did I miss anything? Are there any way either to bypass this check either to fix this use case?

I believe issue #3857 on tracker is related.

Best regards,

Romaric

[Herick MOTA]

I am also having issues to run the new chromedriver 92.0.4515.43, currently running on docker container as well. 

If I try to run it in headless mode, it's working fine, but if I try to run by triggering the browser to open, it gets stuck data; url on the address bar. 

It was running all fine before this latest release.

[Tom R]

I have the same issue running `92.0.4515.107`. Did anyone solve this?

[Tom R]

I found a (very) temporary workaround: I downgraded to 91.0.4472.101 which already supports Chrome 92, but does not have strict host validation.

[Romaric Drigon]

That's what I did too, but indeed it is very temporary.

Looking at the source code, I don't see any way around this parameter. So for now the only thing I found was to "+1" the related issue, as it requires code modification, if you want to participate too:

https://bugs.chromium.org/p/chromedriver/issues/detail?id=3857

[Herick MOTA]

I found out and posted it on stackoverflow.
It worked for my case https://stackoverflow.com/a/68527358/13234986

[William Flanagan]

So, in the case where you are attempting to drive container-based tests with an outside browser, the current solutions are all pretty much non-starters.

If you're driving the outside browser, one must currently downgrade their primary Chrome browser to 91 to use the 91 version of the chromedriver. This is on developer's daily driver machines. On MacOs at least, the Chromedriver V91 does not driver the current version of Chrome successfully. 

Older versions of browsers don't effectively test edge cases well. Many/most of our customers regularly update their browsers. So, we're stuck testing with an older browser, and having to do a lot of very specific configuration to get this this up and running (it's fragile).  

Further, if your environment is based on Devcontainers (VSCode Containers), like ours is, it basically won't work in this current configuration. We rely on being able to set the hostname ("host.docker.internal") and this won't work with current versions of the chromedriver. 

There needs to be some way to set explicit hostnames if you're not going to ACTUALLY allow all with the "--whitelisted-ips" flag. The message that comes up says all IPs will be allowed. But, this isn't the case. Because traffic from the domain host.docker.internal is NOT allowed. 

This will be more urgent the more that containerization is used, which is still on the rise. 

I'm not sure how else to request help to fix this. I've spent the better part of 2 days now trying to get around this. 

If anyone has suggestions, I'm all ears. 

[Romaric Drigon]

Hello,

In my case, I moved back to Selenium, using "selenium/chrome-standalone" Docker image. That way Selenium is acting like a proxy, translating remote requests to local ones.

It feels like a downgrade, and it is... I hope chromedriver will be fixed soon, maybe that can help you meanwhile.

Romaric Drigon

--
You received this message because you are subscribed to a topic in the Google Groups "ChromeDriver Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chromedriver-users/3B1zixDQNSQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromedriver-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/048b7a33-a9a4-46f4-8d96-5bcab44f429en%40googlegroups.com.

[Maksim Sadym]

The ChromeDriver version 96 will have an argument `--allowed-origins=...`, allowing some certain origins, or allowing all of them: https://crrev.com/c/3152019

[Maksim Sadym]

UPD: ChromeDriver 95 should have the argument as well.

[Maksim Sadym]

ChromeDriver 95.0.4638.10 has been released