John, quick question for you on using exports with type="rpc"....was the intent to export the rpc name when the feature registers it or when a feature calls it? I want to use it for when a feature calls it, I just want to make sure that was the intent.
-Ryan Email: rjbax...@us.ibm.com Phone: 978-899-3041 developerWorks Profile From: John Hjelmstad <johnfa...@gmail.com> To: Ryan J Baxter/Westford/IBM@Lotus, Cc: dev@shindig.apache.org, Andrew E Davis <andrew_e_davis%ib...@notesdev.ibm.com>, Paul Lindner <lind...@inuus.com> Date: 08/11/2011 08:19 PM Subject: Re: Securing RPC On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rjbax...@us.ibm.com> wrote: > Responses inline. > > > -Ryan > > Email: rjbax...@us.ibm.com > Phone: 978-899-3041 > developerWorks Profile< http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter > > > > > From: John Hjelmstad <fa...@google.com> > To: dev@shindig.apache.org, > Cc: John Hjelmstad <johnfa...@gmail.com>, Paul Lindner < > lind...@inuus.com>, 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 <rjbax...@us.ibm.com> > 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. That was my concern as well, though Dan's point about a gadget that <Requires> a feature that is denied is a good one. The regular recommended approach in this case is to just issue an error in the container, indicating that the gadget cannot be rendered in the first place. Under that assertion, the problem space is reduced to essentially nothing. If any rpc is denied that is provided by a <Requires>'d feature, the gadget fails. If the feature is <Optional>, the gadget should behave appropriately anyway. > > > > > >> > >> -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: rjbax...@us.ibm.com > >> Phone: 978-899-3041 > >> developerWorks Profile > >> > >> > > >
