We surely need a way to make this generic since cleanString looks for specific keywords to filter. I will take a look at this. Using @Parameter may have its own limitations like running through the entire list of parameters per API before deciding which ones to exclude. But let me take a look.
I believe we can mark 4406 resolved. Thanks, Mandar On Sat, Mar 8, 2014 at 3:46 AM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > Mandar, you want to take it? > > On Fri, Mar 7, 2014 at 11:12 PM, Alena Prokharchyk > <alena.prokharc...@citrix.com> wrote: > > And here is the Jira ticket: > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-6213 > > > > "Add new field to API @Parameter indicating if the param should be > skipped > > from logs" > > > > -Alena. > > > > On 3/7/14, 1:47 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > > > >>no problem, glad we agree. > >> > >>On Fri, Mar 7, 2014 at 8:38 PM, Alena Prokharchyk > >><alena.prokharc...@citrix.com> wrote: > >>> Ok, got it, somehow missed the "hardcoded" parameters part. In this > case > >>> true is fine as the parameter in @ApiCommand just triggers the > >>>validation. > >>> We only have to fix one part - instead of hardcoding the parameter(s) > to > >>> hide, we have to come up with the new parameter in @Parameter to > trigger > >>> the exclusion from the logs. > >>> > >>> Thank you, > >>> Alena. > >>> > >>> On 3/7/14, 11:32 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > >>> > >>>>Alena, I can see I am not being clear because what you say is the > >>>>sensible way and apart from the parameter level exactly what happens. > >>>> > >>>>The parameter thing is an enhancement that we can make on top of this. > >>>>At the moment it only obfuscate a set of parameters with a fixed set > >>>>of names. We will have to have a new discussion of what the desirable > >>>>default is however. I say security first. but let's not have that > >>>>discussion in this thread. > >>>> > >>>>Hope this clarifies, > >>>>Daan > >>>> > >>>>On Fri, Mar 7, 2014 at 8:21 PM, Alena Prokharchyk > >>>><alena.prokharc...@citrix.com> wrote: > >>>>> Daan, if the default comes as true for the command, I assume that the > >>>>>user > >>>>> won¹t see the command logged at all? Unless he overrides it. > >>>>> I assume sensitive=³true² means not ³analyze the command² but rather > >>>>> ³don¹t log the command². That doesn¹t seem right to me. > >>>>> > >>>>> True would seem right to me if the parameter is defined on both > >>>>> parameter/command level (which is not how it works today). Then > >>>>>parameter > >>>>> in @ApiCommand annotation will just trigger the analyze for sensitive > >>>>> parameters, and the parameter in the @Parameter will tell whether to > >>>>>log > >>>>> the parameter itself. > >>>>> > >>>>> > >>>>> -Alena. > >>>>> > >>>>> On 3/7/14, 10:51 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> > wrote: > >>>>> > >>>>>>On Fri, Mar 7, 2014 at 7:31 PM, Alena Prokharchyk > >>>>>><alena.prokharc...@citrix.com> wrote: > >>>>>>> And the defaults should be false, > >>>>>> > >>>>>> > >>>>>>I don't agree, The true case does nothing if no fields are recognized > >>>>>>as sensitive, but it the flase case skips sensitive data containing > >>>>>>log messages. The only consquence of true as default is a performance > >>>>>>penalty that we were paying in the old case anyhow. > >>>>>> > >>>>>>-- > >>>>>>Daan > >>>>> > >>>> > >>>> > >>>> > >>>>-- > >>>>Daan > >>> > >> > >> > >> > >>-- > >>Daan > > > > > > -- > Daan > >
