You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I want the processor to never redact specific values, such as email addresses from specific domains. For example, we need [email protected] to be redacted for compliance purposes, but not [email protected]
Describe the solution you'd like
Add an allowed_values configuration option that is a list of regexes (same as blocked_values), then never redact values that match at least one allowed_values regex (even if it also matches a blocked_values regex).
The blocked_values uses Go's regexp package, which doesn't support negative lookahead, which could have been another alternative. There may be workarounds by incrementally excluding matches, but they result in very complex and hard to maintain patterns (especially if multiple patterns need to be allowed, e.g., multiple email domains)
Additional context
I'm happy to contribute a PR if my proposed solution is acceptable
The text was updated successfully, but these errors were encountered:
Component(s)
processor/redaction
Is your feature request related to a problem? Please describe.
I want the processor to never redact specific values, such as email addresses from specific domains. For example, we need
[email protected]
to be redacted for compliance purposes, but not[email protected]
Describe the solution you'd like
Add an
allowed_values
configuration option that is a list of regexes (same asblocked_values
), then never redact values that match at least oneallowed_values
regex (even if it also matches ablocked_values
regex).For example, with the given config:
then
[email protected]
would be redacted in the relevant attributes, but[email protected]
wouldn't.Describe alternatives you've considered
The
blocked_values
uses Go'sregexp
package, which doesn't support negative lookahead, which could have been another alternative. There may be workarounds by incrementally excluding matches, but they result in very complex and hard to maintain patterns (especially if multiple patterns need to be allowed, e.g., multiple email domains)Additional context
I'm happy to contribute a PR if my proposed solution is acceptable
The text was updated successfully, but these errors were encountered: