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 <and...@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 <blackn...@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 > >
