[🚀 Feature]: let the UnreachableBrowserException not leak details of the command

Feature and motivation

Motivation

If a UnreachableBrowserException is raised in a sensitive area there will be sensitive information in the logs.

e.g. the basic-auth infos are leaked here

org.openqa.selenium.remote.UnreachableBrowserException: Error communicating with the remote browser. It may have died.
Build info: version: '4.5.0', revision: 'fe167b119a'
System info: os.name: 'Windows Server 2019', os.arch: 'amd64', os.version: '10.0', java.version: '17.0.4.1'
Driver info: com.my.company.ta.driver.factory.SeleniumDrivers$2
Command: [4ade0fd2dd7fa0b55833438a7af7386d, get {url=https://user:[e-mail]/}]
Capabilities ...
Session ID: 4ade0fd2dd7fa0b55833438a7af7386d
Caused by: java.io.UncheckedIOException: java.net.http.HttpTimeoutException: request timed out
Caused by: java.net.http.HttpTimeoutException: request timed out

Feature

There are several options to ensure the parameters are not logged in the CI pipeline:

a) Modify the UnreachableBrowserException to only contain the parameter values if org.openqa.selenium.internal.Debug.IS_DEBUG is set to true. In other cases it should be enought to know the names of the parameters send.

b) Modify the UnreachableBrowserException to respect a new system property e.g. org.openqa.selenium.SUPPRESS_COMMAND_PARAMETERS. If this flag is set only dump the name of the parameters set.

Usage example

We are using encryption to ensure secrets are not visible to regular users in our continuous integration pipeline. E.g. a Jenkins user can view the logs & workspace, but there are only encrypted secrets. The logging will also ensure there are no secrets shown in the build logs.

A UnreachableBrowserException will currently leak this informations to regular users usually not able to read this informations.

[debanjanc01]

@krmahadevan I agree with this that adding the dependency is the easier solution here.

I’ll take your advise and wait for the feedback by the dev group. 😃

Thanks for all the help!

[krmahadevan]

Since I’m new to the codebase I’m not sure if adding the mockito-inline dependency is something advisable/something I should be doing.

The best way to find that out is by having someone from the dev group review it for you 😃

Personally speaking, adding this dependency would be the straight forward way of getting past this mockito roadblock. The round about way to do this would be to alter the Debug class and then provide a reset() and a reinitialize() methods in it, for the sake of testing. I dont know if that’s something that would be welcome.