On 29-Nov-2012, at 12:23 PM, Chip Childers <chip.child...@sungard.com> wrote:
> Rohit,
>
> Thanks... I'll do some debugging to make sure I get it covered off
> correctly. However, the change I did should have eliminated the
> response object from being appended to the auditTrailSb for the
> command in question. Unless I'm reading the code incorrectly (which I
> might be), the fact that the actual logger call happens in the
> ApiServlet class shouldn't matter.
Yes, I checked it gets logged by the ApiServlet class. Thanks for covering that.
Btw folks, I'm at the Venetian now, any idea how may I meet as many of you? A
little bird told me that the registration would be open for Collab12 from 4-7PM
today at the Venetian near Casanova Ballroom. Looking forward to meeting you
all.
Regards.
>
> Good to know about the api_refactoring part... and I do agree that
> pulling sensitive data out in a clean way would be better than the
> simple if/else logic I added.
>
> On Thu, Nov 29, 2012 at 3:13 PM, Rohit Yadav <rohit.ya...@citrix.com> wrote:
>> Committed on 4.0, 515. For 505, I'm not sure fix by Chip will work as
>> logging into api.log happens by the servlet (APIServlet) some fix like this
>> should work:
>>
>> diff --git a/server/src/com/cloud/api/ApiServlet.java
>> b/server/src/com/cloud/api/ApiServlet.java
>> index 8a1d4de..3ab6497 100755
>> --- a/server/src/com/cloud/api/ApiServlet.java
>> +++ b/server/src/com/cloud/api/ApiServlet.java
>> @@ -103,6 +103,13 @@ public class ApiServlet extends HttpServlet {
>> }
>> }
>>
>> + /*
>> + * Strips off sensitive content based on
>> + */
>> + private String stripSensitiveContent(String str) {
>> +
>> + }
>> +
>> @SuppressWarnings("unchecked")
>> private void processRequest(HttpServletRequest req, HttpServletResponse
>> resp) {
>> StringBuffer auditTrailSb = new StringBuffer();
>> @@ -334,7 +341,7 @@ public class ApiServlet extends HttpServlet {
>> auditTrailSb.append(" unknown exception writing api
>> response");
>> }
>> } finally {
>> - s_accessLogger.info(auditTrailSb.toString());
>> +
>> s_accessLogger.info(stripSensitiveContent(auditTrailSb.toString()));
>> // cleanup user context to prevent from being peeked in other
>> request context
>> UserContext.unregisterContext();
>> }
>>
>> Some work on refactoring the api layer is going on api_refactoring, the goal
>> is to separate policy from mechanism and separate tightly coupled security
>> checks using annotations, and also fix and automate docs. Because this the
>> APIServlet.java will have a function, one point to strip out sensitive data
>> like passwords and ssh-keys from logs instead of not logging them
>> completely. I'll start another thread on api_refactoring and this issue.
>>
>> Regards.
>>
>> On 29-Nov-2012, at 9:34 AM, Chip Childers <chip.child...@sungard.com> wrote:
>>
>>> On Wed, Nov 28, 2012 at 7:41 PM, Joe Brockmeier <j...@zonker.net> wrote:
>>>> On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote:
>>>>> I'll look at 505.
>>>>
>>>> Great, thanks!
>>>
>>> Fix committed to master and 4.0 branches (from the air no-less) ;-)
>>>
>>> -chip
>>
>>
