Yes so that was the second part of the work I did...RPC arbitration. Essentially when RPC arbitration is enabled in the container.js the RPC code arbitrate all RPC calls made to the container. If a gadget tried to call an RPC service ID that is not used by any of the features it using (both required and optional) than that RPC request will blocked. For example if a gadget does not use the settitle feature but tries to make an RPC call to the service id set_title it will be blocked.
To enable this , you need to set enableRpcArbitration to true in the container.js -Ryan From: Brian McCullars <[email protected]> To: [email protected], Cc: [email protected] Date: 02/15/2012 02:22 PM Subject: Re: Securing Gadget Features Thanks everyone for your help. One more question. >From the JIRA below it is requesting the security be implemented on RPC calls based on a service ID. So that a gadget can be put on whitelist, and only that gadget can make the RPC call. Has this been implemented as well in Shindig 3.0? On Wed, Feb 15, 2012 at 9:25 AM, Ryan J Baxter <[email protected]> wrote: > Once slight clarification.... > > If gadget administration is enabled and the gadget requires a feature it > has not be allowed to use, the gadget render (and preload if you do it) > will fail. If that same feature is declared to be optional in the gadget > definition than the javascript for that feature will not be loaded and > gadgets.util.hasFeature(...) will return false if the gadget checks to see > if the feature is available. > > -Ryan > > > > > From: Stanton Sievers/Westford/IBM@Lotus > To: [email protected], > Cc: [email protected] > Date: 02/15/2012 07:24 AM > Subject: Re: Securing Gadget Features > > > > Hi Brian, > > Gadget features can be secured via the gadget administration functionality > > that was added to Shindig 3.0 a while back. Here's the JIRA: > https://issues.apache.org/jira/browse/SHINDIG-1601 > > This functionality is turned off by default and you would need to enable > it in your container.js via gadgets.admin.enableFeatureAdministration. The > > default configuration is handled in > /shindig-project/config/gadget-admin.json and there's some sample data in > there. > > If gadget administration is enabled then at gadget load time the Shindig > server won't serve up the JavaScript for a feature for a gadget unless it > is configured to allow it. If you want to dig around in the code you can > find the vast majority of it in the org.apache.shindig.gadgets.admin > package in Shindig. > > -Stanton > > > > From: Henry Saputra <[email protected]> > To: [email protected], > Cc: [email protected] > Date: 02/14/2012 22:32 > Subject: Re: Securing Gadget Features > > > > Hi Brian, > > There is a way to add custom features to Shindig but I dont remember > if there is an built-in mechanism to filter which gadgets could have > access to that features. > > Any gadget definition could simply add <Require> or <Optional> to > include features so I think the easiest way to prevent this is through > your gadget registration flow? > > > - Henry > > On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <[email protected]> > wrote: > > Is there a way to add a custom feature to Shindig and only have specific > > gadgets access that feature? > > > > -- > > Brian McCullars > > Mobile (513) 549-3099 > > Home (513) 549-5884 > > > > -- Brian McCullars Mobile (513) 549-3099 Home (513) 549-5884
