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.ba...@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.hoogl...@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.ba...@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.hoogl...@gmail.com >> >wrote: >> > >> >> On Thu, Nov 28, 2013 at 10:38 AM, Mandar Barve < >> mandar.ba...@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 >> >> >> >> >> >>
