Guess in addition to the command level flag that we have Parameter walk will need to be done only for the already identified "sensitive" responses as discussed on the thread so this may be fine.
Thanks, Mandar On Mon, Mar 10, 2014 at 9:34 AM, Mandar Barve <mandar.ba...@sungard.com>wrote: > 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 >> >> >
