Data masking
Data masking capabilities of RevDeBug for JavaScript projects and how to use them.
Masking variables' values
Built-in data masking can be applied to any variable and will replace the content recorded by RevDeBug with the string "MASK".
To use the capability you need to provide the identifiers or a regular expression that will match the variable name identifiers inside the revdebug.json configuration file.
Configuration file options for data masking
mask - A regular expression that specifies what variable/parameter/attribute names are to be masked (not recorded). This is intended to hide things like passwords and other secrets. Default is /^#?(?:pwd|.*password.*)$/i which will match the standalone name pwd as well as any name which contains the string password, case insensitive. Notice that the # character is included for possible private class attributes, this must be specified explicitly. Also remember to specify the beginning and end of input assertions ^ and $ in order to match a whole identifier instead of just searching through it for a substring (unless that is what you want to do). The masking is done both at compile-time for the majority of variable names but can also be done at runtime for property names of objects. The runtime masking can cause a slowdown in the code execution and so it may be enabled/disabled with the runtime option maskProps (boolean value).
maskProps - a true/false switch enabling variable values masking for objects properties at runtime (defaults to false ).
Source code comments for data masking
You can explicitly mask the values of variables in the source through the use of the /* revdmask */ comment directive. Placed before a variable access which would normally show the value of that variable it will suppress such display. This is intended to hide user passwords and other secrets you may not want someone who is reverse debugging to see. These directives are only positional and don't attach themselves to the variable. That means that if you mask the variable in one place in the source but not in another then it will be visible in that second location unless you mask it there as well.
Disabling UI recording of selected web site elements
When "screen: true" option is used in revdebug.json configuration file RevDeBug will record last seconds of user interaction with the web page to be available with the associated source code execution recording. To exclude parts of the website elements from being recorded at all you need to provide a css class name in the revdebug.json configuration file that you'll use to mark the web page elements for the exclusion.
The css class name or a regular expression matching blocked css classes needs to be specified in "blockClass' option in a "screenOptions" section of revdebug.json file, eg:
You can now add a given css class ("rdb_block" in the example above) to your website elements - after next RevDeBug instrumentation they will stop being recorded and will be replaced with a placeholder of the same dimensions. Or you can specify the name of a class which already exists in your project and all elements with that class will be blocked. If you need to specify a regular expression to match multiple css classes the string needs to starts with a / character, eg. /^secret-.*/i will match all classes starting with "secret-" case insensitive (the "i" flag at the end).
Disabling recording of selected parts of JavaScript code
You can disable selected parts of JavaScript code by using function or script-level directives revdoff (and revdon respectively for the reverse), and revderr for a hybrid approach where most of the code is not recorded but thrown exceptions are - this helps with exception localization for code excluded from recording (modern JavaScript runtimes do not suffer any performance penalty when revderr is used).
For example, to disable recording a function:
function something() {
"revdoff";
// code in this function will not be recorded
}
To disable recording for an entire script you would put the same directive as the first thing in the source code at the top of the file in the global scope. One thing to keep in mind is that if recording is turned off like this then it can not be re-enabled with revdon. In order to be able to enable recording, the recording mode must be revderr due to the required function and program entry and exit code which is needed but not present in revdoff mode.
You can also control the instrumentation of individual statements, expressions, try/catch blocks or many other constructs that are represented by a node in the Javascript AST by prepending that element with a /* revdon */ or /* revderr */ or /* revdoff */ comment. The comment may be a block /* */ or line // comment. These are not perfect though since they are evaluated on entry to a node during a walk of the AST of the program. This means that they won't work at a very granular level like an individual variable in a destructured assignment, mostly they are meant for individual statements, expressions or blocks.
Last updated