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.su...@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.da...@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.sheph...@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
