cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Sensitive Logging
Date Thu, 20 Jul 2017 12:12:32 GMT
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 <blacknext@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 <ntimofeev@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 <blacknext@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 <blacknext@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 <blacknext@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
>> 


Mime
View raw message