Debug values encrypt as XXXX

sanku has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks, I am having a dumper value as follows

$VAR1 = {
          'nodeId' => '1234',
          'param' => {
                     'CardNumber' => '0000000000000000',
                     'Y' => '2000',
                     'M' => '06',
                     'C' => '000',
                   },
          'cont' => '0'
        };
[download]

And i need to chage the CardNumber value as 'XXXXXXXXXXXXXXXX' only during the printing of debug.

Comment on Debug values encrypt as XXXX Download Code

Replies are listed 'Best First'.
Re: Debug values encrypt as XXXX by chrestomanci (Priest) on Jul 18, 2011 at 09:37 UTC
There are special configuration varables in the Data::Dumper namespace that you can set to control how object are dumped. My advice would be to create a dump filter, (see: http://www.effectiveperlprogramming.com/blog/312) or to make use of `$Data::Dumper::Freezer` With `$Data::Dumper::Freezer` you provide the name of a class method that Data::Dumper will attempt to call on each object it dumps, and if that method exists, the object returned will be dumped instead of the original object, so for your class containing credit card numbers you could provide a `hide_secrets()` method that blanks out or encypts the secrets. For other classes there will be no such method, so they will be dumped as they are.	[reply] [d/l] [select]
Re: Debug values encrypt as XXXX by Anonymous Monk on Jul 18, 2011 at 11:39 UTC
Probably the most important consideration for you is to be sure that the debug output cannot somehow wind up on somebody’s web page.	[reply]
Re: Debug values encrypt as XXXX by duelafn (Parson) on Jul 19, 2011 at 17:43 UTC
I've posted RFC: SecureString - Obfuscated / masked strings exept when you need them in response to this post. Hopefully either this post, or that post will yield some responses that are useful to you. Unfortunately, the module I threw togeter for that post is too immature (and totally untested) for me to reccommend at this time. In fact, I would even reccommend against using the module as posted - relying on something so immature is a bad idea in my book. Good Day, Dean	[reply]