cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <blackn...@gmail.com>
Subject Re: Sensitive Logging
Date Thu, 20 Jul 2017 11:06:47 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message