Hi Norbert,
and I agree that hiding sensitive data is important for certain
applications.
You have already mentioned that there are in fact two distinct cases:
1) when sensitive data is represented by a String;
2) when sensitive data is represented by an Object.
My feeling is that the second case is simpler and can be treated
reasonably right away. In that case an approach is available with an
application-specific MessageFormatter subclass. That subclass might be
made aware of all the types that need sensitive data protection and use
a sort of map of protection-aware formatting methods against data types.
The first case is more tricky, and I'm afraid thet we either have to
sacrifice efficiency and use sensitive(password), or ask Ceki to
consider some message pattern syntax extension... Maybe it's the time to
ask Ceki to join... ;)
Regards,
Sergey
On 18.04.15 04:15, Norbert Kiesel wrote:
Hi,
one of the common requirements for my team is to "hide" sensitive
information in production logs, with a varying definition of
sensitive. One idea for this we had was to introduce another pattern
in the format strings, and a global flag that handles that pattern
differently.
Concrete example: `logger.info("user {} has password {}", user,
password);` is ok for debug, but not for production. So instead we
would use `logger.info("user {} has password $$", user, password);`,
and based on some parameter this would be rendered as "user nkiesel
has password secret" or "user nkiesel has password *hidden*".
This looks better than `logger.info("user {} has password {}, user,
sensitive(password)";` and could also be slightly more efficient
(because is would avoid invoking `sensitive` if threshold is higher
than info). However, this approach fails when the parameter is a Java
object and only part of the `toString()` is sensitive. One idea to
solve this would be to support a `SensitiveRenderer` interface with a
"toString(boolean sensitve) method. Then Java objects with sensitive
data could override that.
Anyone out there who has an advice? We have a rough implementation
(with a `static public MessageFormatter.setSensitive(boolean arg);` to
toggle the behavior) that passes the existing test cases (actually
fails the perf tests right now because we used a Matcher.find based
implementation that is 5 times slower), which we of course would be
happy to share if anyone is interested.
</nk>
---
Norbert Kiesel
Systems Architect | Engineering
MetricStream
2600 E. Bayshore Road | Palo Alto, CA - 94303
+1-650-620-2954 | [email protected] | www.metricstream.com
*_Confidentiality Notice:_*This email and any files transmitted with
it are confidential and intended solely for the use of the individual
or entity to whom they are addressed. This message contains
confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this
e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action
in reliance on the contents of this information is strictly prohibited
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
