Hi , the list above of 65 columns are all marked as IsSecure. Maybe the script would be to unmark the not required as secure. Checking the list I feel like is correct, maybe just host fields would be good to keep a change log.

Regards,

Carlos Ruiz

Hi

I agree with , by just the password fields should be changed.

and I liked a lot the idea of marking all the password fields as IsSecure and then make that this kind of column not recorded in log

I’m preparing a patch with a migration script and a code change for that and then send a new PR

Hi , the AD_Column.IsSecure doesn’t mean the field is shown with asterisks, that’s driven with AD_Field.IsEncrypted.

The IsSecure was introduced with IDEMPIERE-1151, and used also in other security cases like IDEMPIERE-1162. That’s precisely to avoid leaking sensitive values via watching context, or as in this case, by watching change log.

So, in other words, a column marked as secure cannot be seen in context, or obtained when parsing context logic or variables, it doesn’t change the edit mask.

If we add my suggestion, then secure columns will not be recorded in change log.

Another “easy” way to achieve what is trying here would be to mark all secure columns as IsAllowLogging=N - and we can add the same in beforeSave of MColumn.

As I posted above, for me, only password, key, pin and salt should be set as secure. Having the rest as secure is just not user friendly (for e.g, you would like to ensure you didn’t enter the wrong host or proxy address. In fact, many apps and web site even has the show password option when you are making changes to it).

Yes - probably we went too far when defined the secure content, hosts are probably not that secure.

From that list, which ones can we declare again as non-secure?