Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAGQtxvbOQe7fT1Jei3YERQ0HTyf4DDHJVBqkF8bE6BQqwWZp6w@mail.gmail.com>
References: 
 <CAJCRRwxRftK=EBeo_8G+1DboWeU0=rBtvY6ooksR7WyNV=57sg@mail.gmail.com>
	<CAGQtxvZKgOkJ74-sEj+ANUc6bpEUz+yb4WOMN1PdLu2BKRD0oQ@mail.gmail.com>
	<CAJCRRwzirz14rei9geZP7=tEnu50q8+_zwcqU-oYd7g9+wHFgg@mail.gmail.com>
	<CAGQtxvb=zKyJd5AHhqY+BZTiRcn+V8m_NDaXqtvq0qDtHHwWcQ@mail.gmail.com>
	<CAJCRRwzV-WuuDTTw4p1PgVY7RoMJNkb0PnfmCRf-Hds61imOxg@mail.gmail.com>
	<CAGQtxvbOQe7fT1Jei3YERQ0HTyf4DDHJVBqkF8bE6BQqwWZp6w@mail.gmail.com>
Date: Mon, 2 Dec 2013 08:24:01 +0530
Message-ID: 
 <CAJCRRwxXBHGk2D2-wF68m3JL2x6qC-WGY7vHW-38iKi=94yGnw@mail.gmail.com>
Subject: Re: [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to
 improve performance - especially of the list APIs
From: Mandar Barve <mandar.barve@sungard.com>
To: dev@cloudstack.apache.org
Cc: nitin.mehta@citrix.com
Content-Type: multipart/alternative; boundary=047d7b3a8c30cc5f5604ec844abf

--047d7b3a8c30cc5f5604ec844abf
Content-Type: text/plain; charset=ISO-8859-1

Thanks Daan.

Thanks,
Mandar


On Fri, Nov 29, 2013 at 5:16 PM, Daan Hoogland <daan.hoogland@gmail.com>wrote:

> Mandar,
>
> I agree, go ahead. Let me know if you need any help.
>
> On Fri, Nov 29, 2013 at 12:40 PM, Mandar Barve <mandar.barve@sungard.com>
> wrote:
> > Hi Daan,
> >    I see your point in not bothering API implementers when it comes to
> > checking or setting the flag. (In my implementation I am proposing flag
> > check using base class ref and set in API child class. Flags and get/set
> > methods are members of the base class.)
> >
> > If the base class has to do the check and set at load time as you suggest
> > here are some things to consider:
> >
> > 1. API command class is loaded by its name at run time.
> > 2. At this time code doesn't know if the API command is carrying
> sensitive
> > data or not.
> > 3. I did not find any annotation in the API command classes for return
> > types that indicate password/secret key that could be used as a simple
> > match string to help decide sensitivity of the class at load time, which
> > means class needs to be modified to set such flag perhaps in its
> > constructor or when it executes the command as suggested earlier. In a
> > nutshell API command class modification is needed.
> >
> > I also agree with your second point that with introduction of another
> > member variable and expectation of it being set by the child class, if
> > there is a developer oversight purpose can get lost. I think by making a
> > base class wrapper method e.g. InformCommandSensitivity abstract we
> should
> > be able to enforce this at compile time. All API command classes will
> have
> > to implement this method leading to setting/resetting of the flag as
> needed.
> >
> > Like you said I don't know the future security implications if any for
> such
> > code.
> >
> > Considering all these I would like to go ahead with the approach I
> > suggested.
> >
> > Thanks,
> > Mandar
> >
> >
> > On Thu, Nov 28, 2013 at 8:07 PM, Daan Hoogland <daan.hoogland@gmail.com
> >wrote:
> >
> >> 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
> >> >>
> >> >>
> >>
> >>
>
>

--047d7b3a8c30cc5f5604ec844abf--