[5.0] Adjust ChromeDriver command to beta releases

[staudenmeir]

The first ChromeDriver beta version has been released and the ChromeDriver command would now download it by default. That's not really useful, as it doesn't work with the stable version of Chrome.

As suspected in #643 (comment), the index page doesn't allow us to differentiate between stable and beta releases. We can get the latest stable version by parsing http://chromedriver.chromium.org/home (which hopefully keeps the current structure).

The command hasn't been released yet, so this is not a breaking change.

[browner12]

is there no HTTPS link we can download from?

[staudenmeir]

The download URL itself has HTTPS: https://github.com/laravel/dusk/blob/5.0/src/Console/ChromeDriverCommand.php#L47

We are only using the HTTP URL to get the latest version number. The regular expression limits it to digits and dots, so I think this should be secure.

Do you see a possible MITM vulnerability?

[browner12]

not necessarily, just more of an "always use HTTPS to be safe" comment.

[staudenmeir]

Unfortunately, https://chromedriver.chromium.org/home doesn't work.

[driesvints]

@staudenmeir could we maybe use Guzzle instead of the file_get_contents call? Wouldn't that be better/safer?

[staudenmeir]

@driesvints I don't think there's a difference in security. I chose file_get_contents() because it doesn't require an additional dependency.

[Wiejeben]

I believe the latest stable release version can also be found at https://chromedriver.storage.googleapis.com/LATEST_RELEASE (see https://chromedriver.storage.googleapis.com/index.html).

Well, at least this version matches the latest stable version from http://chromedriver.chromium.org/home.

[staudenmeir]

@Wiejeben Last week, the LATEST_RELEASE file still contained an outdated ChromeDriver version.

From http://chromedriver.chromium.org/downloads/version-selection:

Please don't rely on the LATEST_RELEASE file without a version suffix. It exists for backward compatibility only, and will be removed in the near future.

[peterfox]

Slight tangent I've been thinking would it not be better to build in a possible detection mechanism for which chrome version you have installed anyways? E.g. for Mac, we can expect the default location to be /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome and if you execute it with the --version flag it will spit out something like Google Chrome 73.0.3683.103. We could then parse that to grab the correct version as we probably shouldn't assume that the latest version is installed anyways. I've found updates to hit some of my devices quicker than other. Is it worth looking into or would it be considered further over kill? I think eventually more people will get hit by version compatibility problems.

[staudenmeir]

@peterfox I've been experimenting with that a while ago, it's definitely feasible.

I wouldn't make it the default behavior, but we could add an option like --auto or --detect.

[drbyte]

@peterfox I was thinking similarly for CI environments too, where their image installs a version we don't control. It'd be nice to just-use-it, or if dusk thinks it's too outdated "then" it can intelligently grab a compatible one.

[peterfox]

@staudenmeir I agree and was also thinking a --detect flag, could also make it an optional value flag to pass in a path to the chrome binary if they're using a custom path.

[staudenmeir]

@peterfox The optional path is a great idea.

[staudenmeir]

I've added the Chrome version detection to my updater package: staudenmeir/dusk-updater