cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs
Date Thu, 28 Nov 2013 14:37:10 GMT
Almost, I would like to see some construct that would allow for child
classes not to bother and let the baseclass do the checking and set
the flag at load time so api implemeters don't have to worry about
this. It is kind of a challenge but using reflection it should be
possible.

As I understand your proposal every implementer of an api has to make
the consideration considering every field of the class. It will work
but automated processing of the api class could prevent oversights by
developers.

On the other hand we will run into privacy and security related
situations not foreseeable right now. I am not sure if what I am
saying will pay off.



On Thu, Nov 28, 2013 at 3:24 PM, Mandar Barve <mandar.barve@sungard.com> wrote:
> Daan,
>     The child classes will "know" (since the API request/response
> parameters are known) at load time if they are to carry sensitive data and
> they can set the flags at class load time/construction like you mentioned.
> Flag check will be at the time of logging.
>
> Did you mean to suggest the same or am I missing something?
>
> Thanks,
> Mandar
>
>
> On Thu, Nov 28, 2013 at 5:22 PM, Daan Hoogland <daan.hoogland@gmail.com>wrote:
>
>> On Thu, Nov 28, 2013 at 10:38 AM, Mandar Barve <mandar.barve@sungard.com>
>> wrote:
>> >
>> > In my opinion we should implement approach #2. I have tested this
>> approach
>> > for couple of sensitive commands list Users and list Accounts. It looks
>> to
>> > work fine.
>>
>>
>> H Mandar, I agree but can some automation be done i.e. recognize
>> sensitive names of fields [pP]assword or varieties thereof? This can
>> be done at construction or even classloadtime and shouldn't impact
>> performance very much.
>>
>> otherwise #2 is more elegant and i mean this as an extension of #2
>>
>>

Mime
View raw message