You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <bl...@gmail.com> on 2017/07/19 12:28:00 UTC
Sensitive Logging
Right now, everything is logged. It would be useful to be able to
configure certain column values to not be logged, especially in a
production environment. The main use case for this would be PII
(Personally Identifiable Information -- passwords, birthdays, social
security numbers, etc). Arguably, that information should be
hashed/encrypted, but it is still not something you'd want leaked into a
log file. Whenever a value isn't to be logged, put "[skipped]" in the log
output.
I think it should work something like this:
DataMap:
Add a "Sensitive Logging" checkbox. Perhaps right under the "Optimistic
Logging" checkbox. Default = ON.
DbEntity / Entity Tab:
Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
"Optimistic Logging" checkbox). Default = ON.
DbEntity / Attributes Tab:
Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
Default = OFF. (OFF means log the value normally. ON means conditionally
log per behavior below).
Upgrading older models:
Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
Behavior:
skipped =
DataMap.ON &&
DbEntity.Entity.ON &&
DbEntity.Entity.Attribute.ON &&
Log.Level > DEBUG
if skipped
log [skipped]
else
log value
In a production environment, log levels are typically
INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
developing, log levels are typically DEBUG/TRACE, and in that case, log the
value.
Also, given that all of the above can be changed at run-time, it allows
flexibility in a production environment to turn the sensitive logging
on/off through admin interfaces should the need arise.
Thoughts?
Thanks,
mrg
Re: Sensitive Logging
Posted by Andrus Adamchik <an...@objectstyle.org>.
If we are talking about plugins, we should not forget that we'll need to support the current Modeler for a long time (very likely at least all the way till 4.1 final), as the new Modeler is a huge effort that should not block other development. I think the most promising vector is building a common Bootique-based plugin platform that can run both new and old modelers (as two separate apps).
Andrus
> On Jul 20, 2017, at 3:08 PM, Michael Gentry <bl...@gmail.com> wrote:
>
> Yes, that would be nice. I've given it a little thought in the new modeler
> I've started, but only a little. Probably at least two extension points
> needed:
>
> 1) Completely separate window (the easiest).
> 2) Access to existing editors (much harder and more fragile if the UI
> layout changes).
>
> Perhaps I should give it some more thought and make the current editors
> themselves plugins...
>
>
> On Thu, Jul 20, 2017 at 7:57 AM, Nikita Timofeev <nt...@objectstyle.com>
> wrote:
>
>> Best way to have everything needed in the Modeler is to support plugins :)
>> Though it won't be an easy task to properly create plugin model (at
>> least in current Modeler)
>>
>> On Thu, Jul 20, 2017 at 2:06 PM, Michael Gentry <bl...@gmail.com>
>> wrote:
>>> That'll be something for me to look into.
>>>
>>> That said, I'll throw out a pro-CM argument to see what people think.
>>>
>>> Maybe I'm odd, but I keep CM open quite often when I'm working because it
>>> gives a good overall view of my data object layer. A concise
>>> presentation. When we push more things to code and other configuration
>>> files, it becomes more of a mental burden, at least for me, to bounce
>>> between lots of different and often bloated sources to track things down.
>>> I understand the desire to keep CM from becoming too bloated, but I also
>>> think CM provides a lot of value, too.
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>>
>>> On Wed, Jul 19, 2017 at 10:46 AM, Nikita Timofeev <
>> ntimofeev@objectstyle.com
>>>> wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Yes I have some new code for extension mechanics in project's XML, it
>>>> can store and load arbitrary data along with model and do it in such
>>>> way that it can be totally disabled at runtime.
>>>> It's used as a proof of concept to store comments and reverse
>>>> engineering config.
>>>>
>>>> But in your case it's really better to create new JdbcLogging
>>>> implementation that can skip some attributes defined by pluggable
>>>> strategy as suggested by Andrus.
>>>>
>>>> On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <bl...@gmail.com>
>>>> wrote:
>>>>> I'll look forward to seeing what is introduced. Ultimately, there
>> aren't
>>>>> that many sensitive fields in an application and a pluggable module to
>>>>> obscure those fields would likely be fine.
>>>>>
>>>>>
>>>>> On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <
>> andrus@objectstyle.org
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> While I totally support solving this problem, I am not keen on
>>>> overloading
>>>>>> the core model with extra properties. We had this discussion under
>> few
>>>>>> different subjects, but it really comes down to the fact that there
>> can
>>>> be
>>>>>> an infinite number of meanings one can associate with their model
>>>>>> attributes (e.g. cayenne-crypto treats certain attributes as
>> encrypted;
>>>> a
>>>>>> serialization framework may treat certain attributes as transient,
>> etc.,
>>>>>> etc.). We just can't support all these things in the core. So I
>> suggest
>>>>>> that we don't.
>>>>>>
>>>>>> Instead we may design this as an extension that can work on top of
>> the
>>>>>> core model. Kind of like cayenne-crypto, that determines which
>> columns
>>>> need
>>>>>> to be encrypted not from the DataMap, but using a pluggable strategy
>>>>>> (column naming convention by default).
>>>>>>
>>>>>> Also in 4.1 we will have a much more flexible model extension
>> mechanism,
>>>>>> which Nikita is about to present. All those requests that we had over
>>>> the
>>>>>> years of adding model comments and other arbitrary metadata will
>> likely
>>>> be
>>>>>> fulfilled soon. So it will be easier to write extensions like the one
>>>> you
>>>>>> propose.
>>>>>>
>>>>>> Andrus
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> Right now, everything is logged. It would be useful to be able to
>>>>>>> configure certain column values to not be logged, especially in a
>>>>>>> production environment. The main use case for this would be PII
>>>>>>> (Personally Identifiable Information -- passwords, birthdays,
>> social
>>>>>>> security numbers, etc). Arguably, that information should be
>>>>>>> hashed/encrypted, but it is still not something you'd want leaked
>>>> into a
>>>>>>> log file. Whenever a value isn't to be logged, put "[skipped]" in
>> the
>>>>>> log
>>>>>>> output.
>>>>>>>
>>>>>>> I think it should work something like this:
>>>>>>>
>>>>>>> DataMap:
>>>>>>>
>>>>>>> Add a "Sensitive Logging" checkbox. Perhaps right under the
>>>> "Optimistic
>>>>>>> Logging" checkbox. Default = ON.
>>>>>>>
>>>>>>>
>>>>>>> DbEntity / Entity Tab:
>>>>>>>
>>>>>>> Add a "Sensitive Logging" checkbox (basically mirroring the
>> ObjEntity
>>>>>>> "Optimistic Logging" checkbox). Default = ON.
>>>>>>>
>>>>>>>
>>>>>>> DbEntity / Attributes Tab:
>>>>>>>
>>>>>>> Add a "Sensitive Logging" checkbox column (beside PK and
>> Mandatory).
>>>>>>> Default = OFF. (OFF means log the value normally. ON means
>>>>>> conditionally
>>>>>>> log per behavior below).
>>>>>>>
>>>>>>>
>>>>>>> Upgrading older models:
>>>>>>>
>>>>>>> Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
>>>>>>>
>>>>>>>
>>>>>>> Behavior:
>>>>>>>
>>>>>>> skipped =
>>>>>>> DataMap.ON &&
>>>>>>> DbEntity.Entity.ON &&
>>>>>>> DbEntity.Entity.Attribute.ON &&
>>>>>>> Log.Level > DEBUG
>>>>>>>
>>>>>>> if skipped
>>>>>>> log [skipped]
>>>>>>> else
>>>>>>> log value
>>>>>>>
>>>>>>>
>>>>>>> In a production environment, log levels are typically
>>>>>>> INFO/WARN/ERROR/FATAL, so factor that into the skipping equation.
>> When
>>>>>>> developing, log levels are typically DEBUG/TRACE, and in that case,
>>>> log
>>>>>> the
>>>>>>> value.
>>>>>>>
>>>>>>> Also, given that all of the above can be changed at run-time, it
>>>> allows
>>>>>>> flexibility in a production environment to turn the sensitive
>> logging
>>>>>>> on/off through admin interfaces should the need arise.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> mrg
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Nikita Timofeev
>>>>
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>
Re: Sensitive Logging
Posted by Michael Gentry <bl...@gmail.com>.
Yes, that would be nice. I've given it a little thought in the new modeler
I've started, but only a little. Probably at least two extension points
needed:
1) Completely separate window (the easiest).
2) Access to existing editors (much harder and more fragile if the UI
layout changes).
Perhaps I should give it some more thought and make the current editors
themselves plugins...
On Thu, Jul 20, 2017 at 7:57 AM, Nikita Timofeev <nt...@objectstyle.com>
wrote:
> Best way to have everything needed in the Modeler is to support plugins :)
> Though it won't be an easy task to properly create plugin model (at
> least in current Modeler)
>
> On Thu, Jul 20, 2017 at 2:06 PM, Michael Gentry <bl...@gmail.com>
> wrote:
> > That'll be something for me to look into.
> >
> > That said, I'll throw out a pro-CM argument to see what people think.
> >
> > Maybe I'm odd, but I keep CM open quite often when I'm working because it
> > gives a good overall view of my data object layer. A concise
> > presentation. When we push more things to code and other configuration
> > files, it becomes more of a mental burden, at least for me, to bounce
> > between lots of different and often bloated sources to track things down.
> > I understand the desire to keep CM from becoming too bloated, but I also
> > think CM provides a lot of value, too.
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Wed, Jul 19, 2017 at 10:46 AM, Nikita Timofeev <
> ntimofeev@objectstyle.com
> >> wrote:
> >
> >> Hi Michael,
> >>
> >> Yes I have some new code for extension mechanics in project's XML, it
> >> can store and load arbitrary data along with model and do it in such
> >> way that it can be totally disabled at runtime.
> >> It's used as a proof of concept to store comments and reverse
> >> engineering config.
> >>
> >> But in your case it's really better to create new JdbcLogging
> >> implementation that can skip some attributes defined by pluggable
> >> strategy as suggested by Andrus.
> >>
> >> On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <bl...@gmail.com>
> >> wrote:
> >> > I'll look forward to seeing what is introduced. Ultimately, there
> aren't
> >> > that many sensitive fields in an application and a pluggable module to
> >> > obscure those fields would likely be fine.
> >> >
> >> >
> >> > On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <
> andrus@objectstyle.org
> >> >
> >> > wrote:
> >> >
> >> >> Hi Mike,
> >> >>
> >> >> While I totally support solving this problem, I am not keen on
> >> overloading
> >> >> the core model with extra properties. We had this discussion under
> few
> >> >> different subjects, but it really comes down to the fact that there
> can
> >> be
> >> >> an infinite number of meanings one can associate with their model
> >> >> attributes (e.g. cayenne-crypto treats certain attributes as
> encrypted;
> >> a
> >> >> serialization framework may treat certain attributes as transient,
> etc.,
> >> >> etc.). We just can't support all these things in the core. So I
> suggest
> >> >> that we don't.
> >> >>
> >> >> Instead we may design this as an extension that can work on top of
> the
> >> >> core model. Kind of like cayenne-crypto, that determines which
> columns
> >> need
> >> >> to be encrypted not from the DataMap, but using a pluggable strategy
> >> >> (column naming convention by default).
> >> >>
> >> >> Also in 4.1 we will have a much more flexible model extension
> mechanism,
> >> >> which Nikita is about to present. All those requests that we had over
> >> the
> >> >> years of adding model comments and other arbitrary metadata will
> likely
> >> be
> >> >> fulfilled soon. So it will be easier to write extensions like the one
> >> you
> >> >> propose.
> >> >>
> >> >> Andrus
> >> >>
> >> >>
> >> >>
> >> >> > On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com>
> >> wrote:
> >> >> >
> >> >> > Right now, everything is logged. It would be useful to be able to
> >> >> > configure certain column values to not be logged, especially in a
> >> >> > production environment. The main use case for this would be PII
> >> >> > (Personally Identifiable Information -- passwords, birthdays,
> social
> >> >> > security numbers, etc). Arguably, that information should be
> >> >> > hashed/encrypted, but it is still not something you'd want leaked
> >> into a
> >> >> > log file. Whenever a value isn't to be logged, put "[skipped]" in
> the
> >> >> log
> >> >> > output.
> >> >> >
> >> >> > I think it should work something like this:
> >> >> >
> >> >> > DataMap:
> >> >> >
> >> >> > Add a "Sensitive Logging" checkbox. Perhaps right under the
> >> "Optimistic
> >> >> > Logging" checkbox. Default = ON.
> >> >> >
> >> >> >
> >> >> > DbEntity / Entity Tab:
> >> >> >
> >> >> > Add a "Sensitive Logging" checkbox (basically mirroring the
> ObjEntity
> >> >> > "Optimistic Logging" checkbox). Default = ON.
> >> >> >
> >> >> >
> >> >> > DbEntity / Attributes Tab:
> >> >> >
> >> >> > Add a "Sensitive Logging" checkbox column (beside PK and
> Mandatory).
> >> >> > Default = OFF. (OFF means log the value normally. ON means
> >> >> conditionally
> >> >> > log per behavior below).
> >> >> >
> >> >> >
> >> >> > Upgrading older models:
> >> >> >
> >> >> > Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
> >> >> >
> >> >> >
> >> >> > Behavior:
> >> >> >
> >> >> > skipped =
> >> >> > DataMap.ON &&
> >> >> > DbEntity.Entity.ON &&
> >> >> > DbEntity.Entity.Attribute.ON &&
> >> >> > Log.Level > DEBUG
> >> >> >
> >> >> > if skipped
> >> >> > log [skipped]
> >> >> > else
> >> >> > log value
> >> >> >
> >> >> >
> >> >> > In a production environment, log levels are typically
> >> >> > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation.
> When
> >> >> > developing, log levels are typically DEBUG/TRACE, and in that case,
> >> log
> >> >> the
> >> >> > value.
> >> >> >
> >> >> > Also, given that all of the above can be changed at run-time, it
> >> allows
> >> >> > flexibility in a production environment to turn the sensitive
> logging
> >> >> > on/off through admin interfaces should the need arise.
> >> >> >
> >> >> > Thoughts?
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > mrg
> >> >>
> >> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Nikita Timofeev
> >>
>
>
>
> --
> Best regards,
> Nikita Timofeev
>
Re: Sensitive Logging
Posted by Nikita Timofeev <nt...@objectstyle.com>.
Best way to have everything needed in the Modeler is to support plugins :)
Though it won't be an easy task to properly create plugin model (at
least in current Modeler)
On Thu, Jul 20, 2017 at 2:06 PM, Michael Gentry <bl...@gmail.com> wrote:
> That'll be something for me to look into.
>
> That said, I'll throw out a pro-CM argument to see what people think.
>
> Maybe I'm odd, but I keep CM open quite often when I'm working because it
> gives a good overall view of my data object layer. A concise
> presentation. When we push more things to code and other configuration
> files, it becomes more of a mental burden, at least for me, to bounce
> between lots of different and often bloated sources to track things down.
> I understand the desire to keep CM from becoming too bloated, but I also
> think CM provides a lot of value, too.
>
> Thanks,
>
> mrg
>
>
> On Wed, Jul 19, 2017 at 10:46 AM, Nikita Timofeev <ntimofeev@objectstyle.com
>> wrote:
>
>> Hi Michael,
>>
>> Yes I have some new code for extension mechanics in project's XML, it
>> can store and load arbitrary data along with model and do it in such
>> way that it can be totally disabled at runtime.
>> It's used as a proof of concept to store comments and reverse
>> engineering config.
>>
>> But in your case it's really better to create new JdbcLogging
>> implementation that can skip some attributes defined by pluggable
>> strategy as suggested by Andrus.
>>
>> On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <bl...@gmail.com>
>> wrote:
>> > I'll look forward to seeing what is introduced. Ultimately, there aren't
>> > that many sensitive fields in an application and a pluggable module to
>> > obscure those fields would likely be fine.
>> >
>> >
>> > On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <andrus@objectstyle.org
>> >
>> > wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> While I totally support solving this problem, I am not keen on
>> overloading
>> >> the core model with extra properties. We had this discussion under few
>> >> different subjects, but it really comes down to the fact that there can
>> be
>> >> an infinite number of meanings one can associate with their model
>> >> attributes (e.g. cayenne-crypto treats certain attributes as encrypted;
>> a
>> >> serialization framework may treat certain attributes as transient, etc.,
>> >> etc.). We just can't support all these things in the core. So I suggest
>> >> that we don't.
>> >>
>> >> Instead we may design this as an extension that can work on top of the
>> >> core model. Kind of like cayenne-crypto, that determines which columns
>> need
>> >> to be encrypted not from the DataMap, but using a pluggable strategy
>> >> (column naming convention by default).
>> >>
>> >> Also in 4.1 we will have a much more flexible model extension mechanism,
>> >> which Nikita is about to present. All those requests that we had over
>> the
>> >> years of adding model comments and other arbitrary metadata will likely
>> be
>> >> fulfilled soon. So it will be easier to write extensions like the one
>> you
>> >> propose.
>> >>
>> >> Andrus
>> >>
>> >>
>> >>
>> >> > On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com>
>> wrote:
>> >> >
>> >> > Right now, everything is logged. It would be useful to be able to
>> >> > configure certain column values to not be logged, especially in a
>> >> > production environment. The main use case for this would be PII
>> >> > (Personally Identifiable Information -- passwords, birthdays, social
>> >> > security numbers, etc). Arguably, that information should be
>> >> > hashed/encrypted, but it is still not something you'd want leaked
>> into a
>> >> > log file. Whenever a value isn't to be logged, put "[skipped]" in the
>> >> log
>> >> > output.
>> >> >
>> >> > I think it should work something like this:
>> >> >
>> >> > DataMap:
>> >> >
>> >> > Add a "Sensitive Logging" checkbox. Perhaps right under the
>> "Optimistic
>> >> > Logging" checkbox. Default = ON.
>> >> >
>> >> >
>> >> > DbEntity / Entity Tab:
>> >> >
>> >> > Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
>> >> > "Optimistic Logging" checkbox). Default = ON.
>> >> >
>> >> >
>> >> > DbEntity / Attributes Tab:
>> >> >
>> >> > Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
>> >> > Default = OFF. (OFF means log the value normally. ON means
>> >> conditionally
>> >> > log per behavior below).
>> >> >
>> >> >
>> >> > Upgrading older models:
>> >> >
>> >> > Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
>> >> >
>> >> >
>> >> > Behavior:
>> >> >
>> >> > skipped =
>> >> > DataMap.ON &&
>> >> > DbEntity.Entity.ON &&
>> >> > DbEntity.Entity.Attribute.ON &&
>> >> > Log.Level > DEBUG
>> >> >
>> >> > if skipped
>> >> > log [skipped]
>> >> > else
>> >> > log value
>> >> >
>> >> >
>> >> > In a production environment, log levels are typically
>> >> > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
>> >> > developing, log levels are typically DEBUG/TRACE, and in that case,
>> log
>> >> the
>> >> > value.
>> >> >
>> >> > Also, given that all of the above can be changed at run-time, it
>> allows
>> >> > flexibility in a production environment to turn the sensitive logging
>> >> > on/off through admin interfaces should the need arise.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > mrg
>> >>
>> >>
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>
--
Best regards,
Nikita Timofeev
Re: Sensitive Logging
Posted by Michael Gentry <bl...@gmail.com>.
That'll be something for me to look into.
That said, I'll throw out a pro-CM argument to see what people think.
Maybe I'm odd, but I keep CM open quite often when I'm working because it
gives a good overall view of my data object layer. A concise
presentation. When we push more things to code and other configuration
files, it becomes more of a mental burden, at least for me, to bounce
between lots of different and often bloated sources to track things down.
I understand the desire to keep CM from becoming too bloated, but I also
think CM provides a lot of value, too.
Thanks,
mrg
On Wed, Jul 19, 2017 at 10:46 AM, Nikita Timofeev <ntimofeev@objectstyle.com
> wrote:
> Hi Michael,
>
> Yes I have some new code for extension mechanics in project's XML, it
> can store and load arbitrary data along with model and do it in such
> way that it can be totally disabled at runtime.
> It's used as a proof of concept to store comments and reverse
> engineering config.
>
> But in your case it's really better to create new JdbcLogging
> implementation that can skip some attributes defined by pluggable
> strategy as suggested by Andrus.
>
> On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <bl...@gmail.com>
> wrote:
> > I'll look forward to seeing what is introduced. Ultimately, there aren't
> > that many sensitive fields in an application and a pluggable module to
> > obscure those fields would likely be fine.
> >
> >
> > On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <andrus@objectstyle.org
> >
> > wrote:
> >
> >> Hi Mike,
> >>
> >> While I totally support solving this problem, I am not keen on
> overloading
> >> the core model with extra properties. We had this discussion under few
> >> different subjects, but it really comes down to the fact that there can
> be
> >> an infinite number of meanings one can associate with their model
> >> attributes (e.g. cayenne-crypto treats certain attributes as encrypted;
> a
> >> serialization framework may treat certain attributes as transient, etc.,
> >> etc.). We just can't support all these things in the core. So I suggest
> >> that we don't.
> >>
> >> Instead we may design this as an extension that can work on top of the
> >> core model. Kind of like cayenne-crypto, that determines which columns
> need
> >> to be encrypted not from the DataMap, but using a pluggable strategy
> >> (column naming convention by default).
> >>
> >> Also in 4.1 we will have a much more flexible model extension mechanism,
> >> which Nikita is about to present. All those requests that we had over
> the
> >> years of adding model comments and other arbitrary metadata will likely
> be
> >> fulfilled soon. So it will be easier to write extensions like the one
> you
> >> propose.
> >>
> >> Andrus
> >>
> >>
> >>
> >> > On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com>
> wrote:
> >> >
> >> > Right now, everything is logged. It would be useful to be able to
> >> > configure certain column values to not be logged, especially in a
> >> > production environment. The main use case for this would be PII
> >> > (Personally Identifiable Information -- passwords, birthdays, social
> >> > security numbers, etc). Arguably, that information should be
> >> > hashed/encrypted, but it is still not something you'd want leaked
> into a
> >> > log file. Whenever a value isn't to be logged, put "[skipped]" in the
> >> log
> >> > output.
> >> >
> >> > I think it should work something like this:
> >> >
> >> > DataMap:
> >> >
> >> > Add a "Sensitive Logging" checkbox. Perhaps right under the
> "Optimistic
> >> > Logging" checkbox. Default = ON.
> >> >
> >> >
> >> > DbEntity / Entity Tab:
> >> >
> >> > Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
> >> > "Optimistic Logging" checkbox). Default = ON.
> >> >
> >> >
> >> > DbEntity / Attributes Tab:
> >> >
> >> > Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
> >> > Default = OFF. (OFF means log the value normally. ON means
> >> conditionally
> >> > log per behavior below).
> >> >
> >> >
> >> > Upgrading older models:
> >> >
> >> > Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
> >> >
> >> >
> >> > Behavior:
> >> >
> >> > skipped =
> >> > DataMap.ON &&
> >> > DbEntity.Entity.ON &&
> >> > DbEntity.Entity.Attribute.ON &&
> >> > Log.Level > DEBUG
> >> >
> >> > if skipped
> >> > log [skipped]
> >> > else
> >> > log value
> >> >
> >> >
> >> > In a production environment, log levels are typically
> >> > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
> >> > developing, log levels are typically DEBUG/TRACE, and in that case,
> log
> >> the
> >> > value.
> >> >
> >> > Also, given that all of the above can be changed at run-time, it
> allows
> >> > flexibility in a production environment to turn the sensitive logging
> >> > on/off through admin interfaces should the need arise.
> >> >
> >> > Thoughts?
> >> >
> >> > Thanks,
> >> >
> >> > mrg
> >>
> >>
>
>
>
> --
> Best regards,
> Nikita Timofeev
>
Re: Sensitive Logging
Posted by Nikita Timofeev <nt...@objectstyle.com>.
Hi Michael,
Yes I have some new code for extension mechanics in project's XML, it
can store and load arbitrary data along with model and do it in such
way that it can be totally disabled at runtime.
It's used as a proof of concept to store comments and reverse
engineering config.
But in your case it's really better to create new JdbcLogging
implementation that can skip some attributes defined by pluggable
strategy as suggested by Andrus.
On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <bl...@gmail.com> wrote:
> I'll look forward to seeing what is introduced. Ultimately, there aren't
> that many sensitive fields in an application and a pluggable module to
> obscure those fields would likely be fine.
>
>
> On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> Hi Mike,
>>
>> While I totally support solving this problem, I am not keen on overloading
>> the core model with extra properties. We had this discussion under few
>> different subjects, but it really comes down to the fact that there can be
>> an infinite number of meanings one can associate with their model
>> attributes (e.g. cayenne-crypto treats certain attributes as encrypted; a
>> serialization framework may treat certain attributes as transient, etc.,
>> etc.). We just can't support all these things in the core. So I suggest
>> that we don't.
>>
>> Instead we may design this as an extension that can work on top of the
>> core model. Kind of like cayenne-crypto, that determines which columns need
>> to be encrypted not from the DataMap, but using a pluggable strategy
>> (column naming convention by default).
>>
>> Also in 4.1 we will have a much more flexible model extension mechanism,
>> which Nikita is about to present. All those requests that we had over the
>> years of adding model comments and other arbitrary metadata will likely be
>> fulfilled soon. So it will be easier to write extensions like the one you
>> propose.
>>
>> Andrus
>>
>>
>>
>> > On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com> wrote:
>> >
>> > Right now, everything is logged. It would be useful to be able to
>> > configure certain column values to not be logged, especially in a
>> > production environment. The main use case for this would be PII
>> > (Personally Identifiable Information -- passwords, birthdays, social
>> > security numbers, etc). Arguably, that information should be
>> > hashed/encrypted, but it is still not something you'd want leaked into a
>> > log file. Whenever a value isn't to be logged, put "[skipped]" in the
>> log
>> > output.
>> >
>> > I think it should work something like this:
>> >
>> > DataMap:
>> >
>> > Add a "Sensitive Logging" checkbox. Perhaps right under the "Optimistic
>> > Logging" checkbox. Default = ON.
>> >
>> >
>> > DbEntity / Entity Tab:
>> >
>> > Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
>> > "Optimistic Logging" checkbox). Default = ON.
>> >
>> >
>> > DbEntity / Attributes Tab:
>> >
>> > Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
>> > Default = OFF. (OFF means log the value normally. ON means
>> conditionally
>> > log per behavior below).
>> >
>> >
>> > Upgrading older models:
>> >
>> > Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
>> >
>> >
>> > Behavior:
>> >
>> > skipped =
>> > DataMap.ON &&
>> > DbEntity.Entity.ON &&
>> > DbEntity.Entity.Attribute.ON &&
>> > Log.Level > DEBUG
>> >
>> > if skipped
>> > log [skipped]
>> > else
>> > log value
>> >
>> >
>> > In a production environment, log levels are typically
>> > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
>> > developing, log levels are typically DEBUG/TRACE, and in that case, log
>> the
>> > value.
>> >
>> > Also, given that all of the above can be changed at run-time, it allows
>> > flexibility in a production environment to turn the sensitive logging
>> > on/off through admin interfaces should the need arise.
>> >
>> > Thoughts?
>> >
>> > Thanks,
>> >
>> > mrg
>>
>>
--
Best regards,
Nikita Timofeev
Re: Sensitive Logging
Posted by Michael Gentry <bl...@gmail.com>.
I'll look forward to seeing what is introduced. Ultimately, there aren't
that many sensitive fields in an application and a pluggable module to
obscure those fields would likely be fine.
On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> Hi Mike,
>
> While I totally support solving this problem, I am not keen on overloading
> the core model with extra properties. We had this discussion under few
> different subjects, but it really comes down to the fact that there can be
> an infinite number of meanings one can associate with their model
> attributes (e.g. cayenne-crypto treats certain attributes as encrypted; a
> serialization framework may treat certain attributes as transient, etc.,
> etc.). We just can't support all these things in the core. So I suggest
> that we don't.
>
> Instead we may design this as an extension that can work on top of the
> core model. Kind of like cayenne-crypto, that determines which columns need
> to be encrypted not from the DataMap, but using a pluggable strategy
> (column naming convention by default).
>
> Also in 4.1 we will have a much more flexible model extension mechanism,
> which Nikita is about to present. All those requests that we had over the
> years of adding model comments and other arbitrary metadata will likely be
> fulfilled soon. So it will be easier to write extensions like the one you
> propose.
>
> Andrus
>
>
>
> > On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com> wrote:
> >
> > Right now, everything is logged. It would be useful to be able to
> > configure certain column values to not be logged, especially in a
> > production environment. The main use case for this would be PII
> > (Personally Identifiable Information -- passwords, birthdays, social
> > security numbers, etc). Arguably, that information should be
> > hashed/encrypted, but it is still not something you'd want leaked into a
> > log file. Whenever a value isn't to be logged, put "[skipped]" in the
> log
> > output.
> >
> > I think it should work something like this:
> >
> > DataMap:
> >
> > Add a "Sensitive Logging" checkbox. Perhaps right under the "Optimistic
> > Logging" checkbox. Default = ON.
> >
> >
> > DbEntity / Entity Tab:
> >
> > Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
> > "Optimistic Logging" checkbox). Default = ON.
> >
> >
> > DbEntity / Attributes Tab:
> >
> > Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
> > Default = OFF. (OFF means log the value normally. ON means
> conditionally
> > log per behavior below).
> >
> >
> > Upgrading older models:
> >
> > Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
> >
> >
> > Behavior:
> >
> > skipped =
> > DataMap.ON &&
> > DbEntity.Entity.ON &&
> > DbEntity.Entity.Attribute.ON &&
> > Log.Level > DEBUG
> >
> > if skipped
> > log [skipped]
> > else
> > log value
> >
> >
> > In a production environment, log levels are typically
> > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
> > developing, log levels are typically DEBUG/TRACE, and in that case, log
> the
> > value.
> >
> > Also, given that all of the above can be changed at run-time, it allows
> > flexibility in a production environment to turn the sensitive logging
> > on/off through admin interfaces should the need arise.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > mrg
>
>
Re: Sensitive Logging
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Mike,
While I totally support solving this problem, I am not keen on overloading the core model with extra properties. We had this discussion under few different subjects, but it really comes down to the fact that there can be an infinite number of meanings one can associate with their model attributes (e.g. cayenne-crypto treats certain attributes as encrypted; a serialization framework may treat certain attributes as transient, etc., etc.). We just can't support all these things in the core. So I suggest that we don't.
Instead we may design this as an extension that can work on top of the core model. Kind of like cayenne-crypto, that determines which columns need to be encrypted not from the DataMap, but using a pluggable strategy (column naming convention by default).
Also in 4.1 we will have a much more flexible model extension mechanism, which Nikita is about to present. All those requests that we had over the years of adding model comments and other arbitrary metadata will likely be fulfilled soon. So it will be easier to write extensions like the one you propose.
Andrus
> On Jul 19, 2017, at 3:28 PM, Michael Gentry <bl...@gmail.com> wrote:
>
> Right now, everything is logged. It would be useful to be able to
> configure certain column values to not be logged, especially in a
> production environment. The main use case for this would be PII
> (Personally Identifiable Information -- passwords, birthdays, social
> security numbers, etc). Arguably, that information should be
> hashed/encrypted, but it is still not something you'd want leaked into a
> log file. Whenever a value isn't to be logged, put "[skipped]" in the log
> output.
>
> I think it should work something like this:
>
> DataMap:
>
> Add a "Sensitive Logging" checkbox. Perhaps right under the "Optimistic
> Logging" checkbox. Default = ON.
>
>
> DbEntity / Entity Tab:
>
> Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity
> "Optimistic Logging" checkbox). Default = ON.
>
>
> DbEntity / Attributes Tab:
>
> Add a "Sensitive Logging" checkbox column (beside PK and Mandatory).
> Default = OFF. (OFF means log the value normally. ON means conditionally
> log per behavior below).
>
>
> Upgrading older models:
>
> Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF.
>
>
> Behavior:
>
> skipped =
> DataMap.ON &&
> DbEntity.Entity.ON &&
> DbEntity.Entity.Attribute.ON &&
> Log.Level > DEBUG
>
> if skipped
> log [skipped]
> else
> log value
>
>
> In a production environment, log levels are typically
> INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When
> developing, log levels are typically DEBUG/TRACE, and in that case, log the
> value.
>
> Also, given that all of the above can be changed at run-time, it allows
> flexibility in a production environment to turn the sensitive logging
> on/off through admin interfaces should the need arise.
>
> Thoughts?
>
> Thanks,
>
> mrg