Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 80C78104F2 for ; Thu, 28 Nov 2013 14:38:00 +0000 (UTC) Received: (qmail 61116 invoked by uid 500); 28 Nov 2013 14:37:57 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 61074 invoked by uid 500); 28 Nov 2013 14:37:56 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 61062 invoked by uid 99); 28 Nov 2013 14:37:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Nov 2013 14:37:55 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of daan.hoogland@gmail.com designates 209.85.223.179 as permitted sender) Received: from [209.85.223.179] (HELO mail-ie0-f179.google.com) (209.85.223.179) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Nov 2013 14:37:51 +0000 Received: by mail-ie0-f179.google.com with SMTP id x13so14739800ief.10 for ; Thu, 28 Nov 2013 06:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ls7tByGcS7ySwoNdtTHwtZW24n1VaH4hxYQaNunmYvQ=; b=ruykTsnemTSQYL4+1lihB6jHVN87FK4LZ3rfrRUsvmcM+3AtTMH6udIXAb4btUXTut ar70OqnUbhDlfaOTw2ILeK/e1WcA5m1un9b/ZxUUpiDD8NI4+IPtR7LWd4Tza6RPpEir EAe4RhJxj8pfOBWq52ijVv4tn/KhDDB0fR7uEubKZuPv9cX50oWuh0YzVsMOBts8j6gR 6H8IXxUvdUZsH5N/0MnFVeQXofig9CtbEzNAWEY9uyZRMOgx/bGZGXFhsdKxmS3TLeSH nk9qLPbdprHg4OULtH/ypuoTUV7OKiVPFiVdNSpRMv8j4UOQtgPhSq6K8y4fraDIyaKJ MObg== X-Received: by 10.43.117.131 with SMTP id fm3mr28154267icc.33.1385649450681; Thu, 28 Nov 2013 06:37:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.226.135 with HTTP; Thu, 28 Nov 2013 06:37:10 -0800 (PST) In-Reply-To: References: From: Daan Hoogland Date: Thu, 28 Nov 2013 15:37:10 +0100 Message-ID: Subject: Re: [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs To: dev Cc: nitin.mehta@citrix.com Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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 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 wrote: > >> On Thu, Nov 28, 2013 at 10:38 AM, Mandar Barve >> 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 >> >>