The spring stuff doesn't help. This discussion didn't really go anywhere and there weren't much comments. I'd say at this point we just put together a proposal. Give me 5 minutes and I'll throw up a proposal in a different thread.
Darren On Thu, Oct 24, 2013 at 1:47 PM, SuichII, Christopher <chris.su...@netapp.com> wrote: > I’d like to see if we can come up with some solution for this issue. Having > ‘add these lines to commands.properties’ is not really an acceptable > installation step for plugins/extensions/etc. > > So, the ideas I’ve seen are: > -Turn commands.properties into a blacklist instead of a whitelist > -Dynamically discover additional commands.properties > > Darren - is there any chance that the Spring modularization stuff you’ve done > would make the latter any easier? > > Are there any others? > > -Chris > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 9, 2013, at 3:49 PM, SuichII, Christopher <chris.su...@netapp.com> > wrote: > >> I just wanted to add a little clarification from a plugin perspective. >> >> Having commands.properties as a whitelist just adds another place that >> plugins have to register with CloudStack. For plugins that do not intend on >> being a part of the CloudStack source, this is actually quite tricky. >> Currently, to add entries to commands.properties, any plugin like this would >> either need to tell the CS administrator to manually modify this file (error >> prone, laborious and an uncommon installation practice) or develop an >> installation script to modify commands.properties when installing, updating >> or uninstalling the plugin (also error prone and scary). >> >> -- >> Chris Suich >> chris.su...@netapp.com >> NetApp Software Engineer >> Data Center Platforms – Cloud Solutions >> Citrix, Cisco & Red Hat >> >> On Oct 9, 2013, at 1:08 AM, Darren Shepherd <darren.s.sheph...@gmail.com> >> wrote: >> >>> So I'm saying if you want to disable a command you put myBadCmd=0 in >>> the commands.properties. So yes, a blacklist over a whitelist. For >>> people paranoid about maybe some command exists that they don't know >>> about, we can even add a "blacklist=false to the command properties. >>> Then the commands.properites becomes the all mighty master of what is >>> allowed (a whitelist). But by default, I think the file should be >>> empty and default to what is defined by the API annotation. >>> >>> Darren >>> >>> On Tue, Oct 8, 2013 at 5:45 PM, SuichII, Christopher >>> <chris.su...@netapp.com> wrote: >>>> 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 >>>> >> >
