ESAPI Log Pre-Filtering

[Jeremiah Stacey]

-SUMMARY-

Presently, the ESAPI Loggers default to forwarding every single log request to the delegate logging implementation, and rely on the client's logger-specific configuration to appropriately handle that event as desired for that environment.  In a recently filed issue it was brought up that there is not currently a method by which a client can modify the default ESAPI logging level.  It is hard-coded to forward all messages.

Effectively, what we're talking about is enabling a new level of log filtering that would be applied in the ESAPI Logger wrapper before the delegate logging implementation is notified of a logging event.

For further details, see https://github.com/ESAPI/esapi-java-legacy/issues/631

We are specifically looking for input/feedback into the desire for this capability in the currently supported ESAPI Logging Implementations: SLF4J, Java, and Log4J (deprecated).

-PROS-

If we move forward with exposing this configuration to pre-filter the log events, then the clients will have a bit more control of what logs are propagated from ESAPI into the delegate logging implementation, and that may result in some performance enhancements for avoiding the lookup on the additional information that ESAPI prepends to log events.

-CONS-

This capability comes at the cost of potentially having to configure and maintain the two logging implementations, and also understand the impacts of the logging levels and associations between the ESAPI library and the client's configured logger.  There are also some technical hurdles that will need to be resolved to reduce the possibility of the creation of incompatible configurations being created.

Some of those hurdles have been identified by kwwall already:

https://github.com/ESAPI/esapi-java-legacy/issues/631#issuecomment-881929323

• How does that interact with a default log level found in a configuration file specific to the type of logger (e.g., SLF4J, JUL) if they are set differently there? At a minimum, we would have to describe in detail how they might conflict.
• How does that affect calls to Logger.always(), which should always log (unless of course the logging were disabled, by setting the default log level to 'OFF').
• Should we even allow 'OFF' (which would disable ESAPI logging) as an option to be set from the ESAPI.properties file?
• If we proceed with this, should we change the meaning of Logger.getESAPILevel() to return the (say) Logger.DefaultLogLevel in ESAPI.properties or should it return the log level of what was set with Logger.setLevel() (which would apply to the specific Logger instance) or the default of what is in the corresponding underlying logger's configuration file(s) (assuming that is even feasible without jumping through too many hoops)?

Other concerns are: Is there something else that we are overlooking? What are the desired use cases that ESAPI needs to support?

-FEEDBACK-

This email chain is the preferred method to engage in discussion.  If any are uncomfortable with responding to the group, then please feel free to reach out to me individually and we can work together to capture your input.  I'm sure kwwall or xeno6696 would also be available for discussion if any prefer those channels.

I appreciate your time, and any feedback regarding this potential extension to the ESAPI library.

-Jeremiah Stacey

[Jeremiah Stacey]

Been about a month and there has been no input on this topic.

Unless someone reaches out in favor of this capability by the end of the month, I plan to recommend to the project leads to simply reject this as a 'wont fix' item at this time.  If a need or use case comes up in the future we can certainly re-assess; however, I would much prefer not to incur this maintenance cost on the project unless it would fulfill a specific and immediate need.

-Jeremiah