Adding Redacted Keys

[clr182]

Goal

Filtering config option is case sensitive and is no longer in line with our notifier spec; as such it should be deprecated in favour of redactedKeys.

Design

Added redactedKeys configuration option, which is case insensitive, as a replacement for the filters configuration option. Additionally due to conflictions the default filters parameters were changed.

Changeset

• Added redactedKeys config option.

• Made redactedKeys case insensitive.

• Changed filters config default parameters from
  {"password", "secret", "Authorization", "Cookie"};
  to
  {"ipAddress", "logLevel"};

• Set refactedKeys config default parameters to
  {"password", "secret", "Authorization", "Cookie"};

Testing

Added and updated tests for filtering mechanism and redactedKeys mechanism.

[tomlongridge]

Unfortunately we're stuck with Configuration.filters being public, so we probably want to keep filters and redactedKeys synchronised otherwise things could get confusing if both are used for any reason. Suggest also setting config.filters here and removing the line from setFilters above?

[tomlongridge]

Looking at the changes, I wonder if in fact this change is more risky as a non-breaking change than I thought as we'll need to compile the filter strings as regexes (L249). At very least we need a try-catch for a PatternSyntaxException, but it makes me a bit nervous even if 99.9% of users will have pretty straightforward key names with an occasional . which will still match a literal ..

@lemnik - thoughts here? The alternative is that we go back to running the two config options independently alongside each other (which I think was @clr182's first take).

[tomlongridge]

I think it would be appropriate to set this to the same instance rather than a different array with the same content. Just in case anyone is amending elements in the array.

Suggested change

	public String[] redactedKeys = new String[]{"password", "secret", "Authorization", "Cookie"};
	public String[] filters = new String[]{"password", "secret", "Authorization", "Cookie"};
	public String[] redactedKeys = new String[]{"password", "secret", "Authorization", "Cookie"};
	public String[] filters = redactedKeys;

[tomlongridge]

It would be worth adding a few tests to verify the expected interplay between filters and redactedKeys

[clr182]

I've added functionality so that when both are called, setRedactedKeys creates a temp array to append the filters to the redactedKeys config option to avoid overwriting.

[tomlongridge]

Looking at the changes, I wonder if in fact this change is more risky as a non-breaking change than I thought as we'll need to compile the filter strings as regexes (L249). At very least we need a try-catch for a PatternSyntaxException, but it makes me a bit nervous even if 99.9% of users will have pretty straightforward key names with an occasional . which will still match a literal ..

@lemnik - thoughts here? The alternative is that we go back to running the two config options independently alongside each other (which I think was @clr182's first take).