pinojs/pino

Feature Request: Capability to redact some paths as well as remove other paths

Opened this issue · 4 comments

ConradLang commented

Currently, the redact options only allow the specified paths to either be redacted or removed based on the remove property.

We have a middleware that logs requests which include all headers. Redacting specific headers e.g. authorization was sufficient but recently, we've had the need to remove other headers which don't have any value diagnosing issues and take up a significant amount of space (20% of the logged message).

We've worked around the redact or remove limitation as follows:

  1. Extend the redactOptions with an optional list of string paths property removePaths.

  2. Use a helper function that constructs the pino redactOptions such that:

    1. The redact.paths is the input paths and removePaths concatenated.

    2. A set is created from removePaths for the censor function to determine if a path should be redacted or removed.

    3. The redact.censor is a function that:

      • Returns undefined if the path is in the removePathsSet.
      • Else returns the censored value (based on the input censor being a function / string / undefined)

A proof of the above is a PR to the light-weight wrapper we use over pino: seek-oss/logger#84 with a caveat where wildcards in the paths are not supported.

Questions:

  1. Is there a reason why pino does not allow redact and remove?
  2. Is having the capability to redact and remove something that I could possibly contribute?
  3. Would support for wildcards in the paths be required?
jsumners commented

I would suggest using a custom serializer.

ConradLang commented

Thanks for the alternative @jsumners.

I think it makes sense when you know the exact shape of the top-level property so that's great for req.headers['header-name'].

Theoretically redaction could be done in the same way ... so why is it treated differently in this case where you'd want both redact and remove?

jsumners commented

In my opinion, it's up to the application author as to which to choose in regard to the requirements of their application. Each method will have a cost.

Maybe @mcollina or @davidmarkclements have different views.

  • 👍1
ConradLang commented

We've gone with a custom serializer (seek-oss/logger#92) and will update our readme with guidance around redact for redaction of properties and a custom serializer for removing properties.

Should this issue be closed or left open since it's still a feature request?