cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikita Timofeev <ntimof...@objectstyle.com>
Subject Re: Sensitive Logging
Date Thu, 20 Jul 2017 11:57:31 GMT
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