Logging SQL parameters

[Michael Dick <mi...@gmail.com>]

Hi all,

Yesterday I opened
OPENJPA-1678<http://issues.apache.org/jira/browse/OPENJPA-1678>to
suppress SQL parameter logging in exceptions and trace. While making
the
SQL values visible is a great benefit when debugging, it can present a
security issue in production (e.g. if the column is a social security
number).

To resolve the problem I've posted a couple of patches to the JIRA. They
both boil down to adding a configuration option in openjpa.Log or
openjpa.ConnectionFactoryProperties to enable/disable parameter printing.

This brings up the question of what the default behavior should be.  With
something like this I'd prefer to err on the side of caution and disable
parameter logging by default. It'd be easy to not notice the parameter
values while testing an application (or to be unconcerned with them since
they're 'dummy data') - if you hit an error in production it's too late and
the cat's out of the bag.

Does anyone feel strongly about the correct default (either way)?

-mike

Re: Logging SQL parameters

[Jeremy Bauer <te...@gmail.com>]

I think we should err on the side of caution here as well, by disabling
parameter logging by default.

-Jeremy

On Thu, Jun 3, 2010 at 11:17 AM, Michael Dick <mi...@gmail.com>wrote:

> Hi all,
>
> Yesterday I opened
> OPENJPA-1678<http://issues.apache.org/jira/browse/OPENJPA-1678>to
> suppress SQL parameter logging in exceptions and trace. While making
> the
> SQL values visible is a great benefit when debugging, it can present a
> security issue in production (e.g. if the column is a social security
> number).
>
> To resolve the problem I've posted a couple of patches to the JIRA. They
> both boil down to adding a configuration option in openjpa.Log or
> openjpa.ConnectionFactoryProperties to enable/disable parameter printing.
>
> This brings up the question of what the default behavior should be.  With
> something like this I'd prefer to err on the side of caution and disable
> parameter logging by default. It'd be easy to not notice the parameter
> values while testing an application (or to be unconcerned with them since
> they're 'dummy data') - if you hit an error in production it's too late and
> the cat's out of the bag.
>
> Does anyone feel strongly about the correct default (either way)?
>
> -mike
>