Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMi+qzAcK7C4q-4HHtLStPj8-9ysEmOb0YcO1pH_StjNbQmgsw@mail.gmail.com>
References: <CAOy5kzMswOFJ2WWeaZtWWzUvdj48B1xn6kNqOhZPNgOvoX6MTA@mail.gmail.com>
 <8EDE83B4-CB4F-4B17-A4FD-9F25984B8947@objectstyle.org> <CAOy5kzN8ORdFrfHkSkJGPLBouEaDZX=fwkMBtTFxLSWYnGiJew@mail.gmail.com>
 <CAMi+qzCPoQzrGd68W+b+t2vARkCW8J8q_MyzEcAm4jBRDT90ig@mail.gmail.com>
 <CAOy5kzPgJkEp26jS+wKD4BmD+Q_DxX2Sjmkdm_0n8Ys70zeJ1g@mail.gmail.com> <CAMi+qzAcK7C4q-4HHtLStPj8-9ysEmOb0YcO1pH_StjNbQmgsw@mail.gmail.com>
From: Michael Gentry <blacknext@gmail.com>
Date: Thu, 20 Jul 2017 08:08:27 -0400
Message-ID: <CAOy5kzMmQ-SjbyOJHH8_0Aj7Azyy4ApgsCAeDGMr1+8jPMoHPQ@mail.gmail.com>
Subject: Re: Sensitive Logging
To: Cayenne Development <dev@cayenne.apache.org>
Content-Type: multipart/alternative; boundary="f403043620840395d30554be9da5"
archived-at: Thu, 20 Jul 2017 12:09:08 -0000

--f403043620840395d30554be9da5
Content-Type: text/plain; charset="UTF-8"

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
>

--f403043620840395d30554be9da5--