Jeff-Lewis / cls-hooked

cls-hooked : CLS using AsynWrap or async_hooks instead of async-listener for node 4.7+

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Decorate errors with non-enumerable properties

jonathansamines opened this issue · comments

When the context is used, seems like all errors get a special error@context property with the current execution context attached.

See:

https://github.com/Jeff-Lewis/cls-hooked/blob/master/context.js#L101
https://github.com/Jeff-Lewis/cls-hooked/blob/master/context.js#L150
https://github.com/Jeff-Lewis/cls-hooked/blob/master/context.js#L175

One of the most common use cases for this module, is to expose the current http request object in the current execution context, so that the application can be traced.

However, if for some reason, an application prints the error object (e.g in an express error handler), with a method that inspects all enumerable properties, then the current request object may be printed, and that may be a problem for a couple of reasons:

  • Developers could be using JSON.stringify which by default throws when circular dependencies are found (request is usually an object with circular dependencies)
  • The request object may container sensitive information, (sessions identifiers, users identifiers, or other secret information that developers may attach to it)

Would it make sense to change those properties to be non enumerable by default?