cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SuichII, Christopher" <Chris.Su...@netapp.com>
Subject Re: [DISCUSS] make commands.properties the exception, not the rule
Date Wed, 09 Oct 2013 00:45:54 GMT
Maybe we could consider switching from a whitelist to a blacklist, then. A whitelist is certainly
easier in terms of a one-step configuration, but a blacklist would allow for much easier plugin
development, installation and removal. Perhaps we could find write a script that generates
the complete list of APIs to create the blacklist from (I know this API exists currently,
but not in the format of commands.properties).

-- 
Chris Suich
chris.suich@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat

On Oct 8, 2013, at 7:11 PM, Prachi Damle <prachi.damle@citrix.com> wrote:

> I think commands.properties is not just providing ACL on the API - but it also serves
as a whitelist of APIs available on the deployment. 
> It can be a one-step configuration option to disable certain functionality.
> 
> Prachi
> 
> 
> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com] 
> Sent: Tuesday, October 08, 2013 3:24 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] make commands.properties the exception, not the rule
> 
> I would like to largely remove commands.properties.  I think most API commands naturally
have a default ACL that should be applied.  I think it makes sense to add to the @APICommand
flags for user, domain, admin.  Then, as an override mechanism, people can edit commands.properties
to change the default ACL.  This would make it such that people could add new commands without
the need to edit commands.properties.
> 
> Thoughts?  How will this play with whatever is being done with rbac?
> 
> Darren


Mime
View raw message