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? > > -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. > > -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. 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 > >
