cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mandar Barve <mandar.ba...@sungardas.com>
Subject Re: Review Request 20117: Pilot patch for CS JIRA 6213
Date Tue, 15 Apr 2014 06:25:01 GMT
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.hoogland@gmail.com>wrote:

> On Tue, Apr 15, 2014 at 6:01 AM, Mandar Barve
> <mandar.barve@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
>

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