Oh all I meant was stuffing the existing search string that cleanString uses with all identified "sensitive" keywords. And I guess if it starts getting GIANT it won't make sense.
On Tue, Apr 15, 2014 at 11:36 AM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > On Tue, Apr 15, 2014 at 6:01 AM, Mandar Barve > <mandar.ba...@sungardas.com> wrote: > > 1. The pilot patch I posted already does this of checking the command > level > > flag first and only for "flagged" commands check the list of "sensitive" > > parameters. I was wondering if that code itself, building list of > sensitive > > parameters as a command can have more than one of these and then > stripping > > them one by one can lead to additional overhead. > > To reduce that overhead, I was thinking the REGEX that cleanString util > > function uses can be generated at application load time walking the list > of > > all only "sensitive" (flagged) command classes followed by the > "sensitive" > > param lists for such classes. At run time when commands are executed all > you > > need to do is for the already flagged "sensitive" commands alone use the > > pre-built REGEX to filter sensitive data. > > I am not sure what you mean by this. The REGEX can get quite complex, > do you envision to create a giant set of or'ed method names? It can be > done but I doubt that building a REGEX is the best thing at load time. > At that time more efficient lists or arrays can be build (or a tree > :P) > Any way tests will tell us. > > -- > Daan >
