cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mandar Barve <mandar.ba...@sungard.com>
Subject [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs
Date Thu, 28 Nov 2013 09:38:54 GMT
Hi All,
    JIRA 4406 expects removal of cleanString() call for performance
improvements. This is called when building audit trail for command
responses and used for removing sensitive data (passwords, secret keys)
from the log buffer. All the API responses do not carry such sensitive
information so pattern matching done by cleanString against all API
response strings can be costly.

I propose following for a solution:

Approach #1

* Check for all the cmds that carry sensitive data each time the logging
function is called to strip sensitive information
* Pros: Easy to implement, with little code impact
* Cons: Won't scale well since any new additional command will mean code
modification required where checks are made

Approach #2

* Modify BaseCmd class to add flags that will store cmd/response sensitivity
* At init these flags will be set to false indicating no cmd req/resp
carries sensitive data
* any child api cmd class that will carry sensitive data in the req/resp
should set the respective flags
* before calling any logging function the flag should be checked and
cleanString should be called only for cmds with flags set

Pro: This approach will scale well as new cmds get added and no additional
changes should be required.
Con: Big change upfront as it will touch all API cmd classes that carry
sensitive information along with BaseCmd class.

NOTE: changes should be simple and straightforward though spread across
multiple classes.

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.

Please let me know if you have concerns, suggestions.

Thanks,
Mandar

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message