Well, yes, this not about long-term storage, this is about protecting the data between receiving the data from the client (say, a query parameter) and actually using the data. See, for example, the Business::OnlinePayment example. It is certainly reasonable to log all transactions which are sent to the payment processing site. Of course, to do that one needs to obfuscate the credit card number. In tight code, this should be reasonably easy to do, but of course, 1) not all code is tight and 2) even in tight code it could be convenient to not have to worry about sensitive data leakage. I could certainly be convinced that something like this module is too much (or more precisely makes promises that it can not reliably deliver), but I don't see how you can "not store such data in the first place" - one has to store sensitive information in variables between receipt of the value and use of the value. This module is for that period.
Update: In particular, this helps saitsfy the PCI DSS requirement (3.2, 3.4) that no sensitive data leak into logs (error logs, trace logs, ...). Some of these error logs may originate from external modules that aren't entirely under your control.
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link or
or How to display code and escape characters
are good places to start.