Is your feature request related to a problem?

Sometimes, even when using test data, we want to prevent some information from being outputted in logs or reports. Today, in wdio, no configuration allows such behaviour. Therefore, we need a proper masking mechanism. The focus here is mainly on the reporters.

The request was triggered primarily to mask the test user's password from the report. This password is sent using the elementSendKeys command, and the text value can be found in the body.text property.

The idea is to implement a mechanism to prevent reporters from accessing sensitive data. To achieve that, we must do it in the webdriver package and, more specifically, in the command.ts, where it triggers the HTTP request to appium and emits the sensitive data as a 'request,' 'performance,' or 'result' event. Moreover, we have some loggers that log sensitive data.

While being on the topic, possible other touchpoints to keep in mind:

• appium have log filters even though it is hard to use.
• BrowserStack has maskCommand even though it's an all-or-nothing. But, it might not mask information in Percy or Insight tools.

Describe the solution you'd like.

As mentioned, since in command.ts, there are several emit and also logging of the sensitive data, the only way to have a solid mechanism is to mask the data there and pass the masked data to everything else besides the HTTP request to appium

The emit events request.performance, command, result, request, and performance were all reviewed to pass the masked body and ensure that sensitive data was concealed.

Some logging with the keywords DATA and COMMAND were also reviewed to pass the proper masked data so we do not leak sensitive information.

Since we pass the masked body to the emit event command and result, all Reporters and BrowserStack tools receive the masked text and will no longer show sensitive data in reports. Note that BrowserStack Text Logs is not affected at all by that, and their maskCommand mechanism still needs to be used!

To use this new mechanism, we must pass the capabilities wdio:maskingPatterns, where it is a RegExp on which we apply .toString(). Otherwise, there is some serialization mechanism losing the literal RegExp value.

Describe alternatives you've considered.

At first, we thought of masking on the onBeforeCommand and onAfterCommand, but the sensitive data would have leaked in other places, like logging.

Additional context

An example of masking after enabling the wdio logger at the INFO level.

Code of Conduct

• I agree to follow this project's Code of Conduct