support separate logger for sensitive information

[mkienenb]

No description provided.

[mkienenb]

Right now, connection details logged from HttpUtility at the debug level include a great deal of useful information along with

• the api login and transaction key
• full dump of the xml request including unmasked credit card number, expiration date, etc.

Can we move the logging of these two items to a separately-configurable logger like "HttpUtility-sensitive"?

I'd like to see the api login and transaction key logging go away completely from the HttpUtility output.

ideally, I'd like to see the xml request filtered to not show any information beyond a generic output. (I suppose masked credit card number would be acceptable).

I think it would also be wise to not output information nor information with the non-sensitive-data logger other than even though this is not strictly required by PCI DSS.

We want to log when transactions occur with enough context to know what those transactions are without making our logs a security risk.

Feature requested in forum here:

https://community.developer.authorize.net/t5/Ideas/Ability-to-log-HttpUtility-calls-without-exposing-sensitive/idi-p/54370

This implementation only moves logging of both the request and the merchant authentication keys to a separate logger and makes no attempt to provide non-sensitive request logging.

[mkienenb]

Unfortunately, while clever, the SensitiveFilterLayout approach to fixing this issue is flawed.

It requires the log4j be used -- not the case for some of our apps.

It requires that the SensitiveFilterLayout be used, which is also not the case for some of our logging.

There's also the chance, although slim, that the masked credit card regexs might mask some other data that just looks like a credit card.

I think a better solution using this approach would be to apply the same logic to the logger directly. Then there'd be no other logging affected by the filtering, and no special layout would be needed. The downside might be toggling between showing and not showing the sensitive data.

I'm going to create a new build with the original fix rebased.

[mkienenb]

Superceeded by PR #168

Support separate logger for sensitive information (take 2)