>I was thinking that the JS would just not be loaded in the iFrame for the
>gadget. But now that I am thinking about this that may not be so good >since it will probably result in errors in the gadget. Returning empty >implementations of the functions is probably a little better, but may >still result in JS errors in the gadget. I would think that gadgets that *require* features that have missing code would have issues no matter what you do. Otherwise, gadgets that *optional* features *should* gate the code that uses those features with checks to see if they actually exist. From: Ryan J Baxter/Westford/IBM@Lotus To: [email protected], Cc: "Andrew E Davis" <andrew_e_davis%[email protected]>, John Hjelmstad <[email protected]>, Paul Lindner <[email protected]> Date: 08/10/2011 08:18 PM Subject: Re: Securing RPC Responses inline. -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: John Hjelmstad <[email protected]> To: [email protected], Cc: John Hjelmstad <[email protected]>, Paul Lindner <[email protected]>, Andrew E Davis/Westford/IBM@IBMUS Date: 08/10/2011 06:10 PM Subject: Re: Securing RPC >Hey Ryan, > >A few comments inline. > >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <[email protected]> wrote: > >> John and Paul, >> >> In May, when Andrew and I were out at Google, we talked to you guys at a >> high level about how to secure features and the RPC functionality in >> Shindig. Andrew and I are at the point where we would like to tackle >> this and would like to keep you guys in the loop with the implementation >> so we can come up with a solid implementation. Based on our conversation >> in May, here is what I have for high level changes that would need to be >> made. >> >> -Add a "feature security service" which will interface with some data >> store describing what features are allowed for a given container. >> > >Sounds good to me. > > >> >> -Possibly add a new gadget renderer or modify the existing gadget render >> code to not return feature code if the feature has not been enabled in a >> given container. >> > >By "not return feature code" do you mean "return empty code" -- or is it an >implicit requirement that symbol names be exported but with empty >implementations? > I was thinking that the JS would just not be loaded in the iFrame for the gadget. But now that I am thinking about this that may not be so good since it will probably result in errors in the gadget. Returning empty implementations of the functions is probably a little better, but may still result in JS errors in the gadget. > >> >> -Add a new element/parameter to the feature XML to allow feature >> developers to specify the RPC endpoints they use in their feature code. >> > >You should be able to use: ><api> > <exports type="rpc">rpc_symbol_name</exports> ></api> > >...for this purpose. I'm excited to see that be put to use. Great I will take a look at that! > > >> >> -Add an "RPC arbitrator" that uses the information from feature security >> service in combination with the RPC endpoints specified in the feature XML >> to either allow or disallow RPC requests made by gadgets. >> > >I assume this piece will be in the container/provider-side JS, true? You >might be able to auto-generate stubs for this from the JS server itself, >without a whole lot of code. > Yeah this will be in the container. We were thinking the RPC code will have a setArbitrator function which can be used to set the arbitrator to use. We were also thinking of pulling down the list of allowed RPC endpoints when the container makes the metadata request for the gadget. Could you elaborate more on what you were thinking with the JS server? >Cheers, >John > > >> >> Please let me know if you have any other thoughts on this topic. >> >> >> -Ryan >> >> Email: [email protected] >> Phone: 978-899-3041 >> developerWorks Profile >> >>
