I mean in the feature.xml
.....
<api>
<export type="rpc">rpc_service_id</export>
<api>
....
I am wondering whether the above export is used to export the service id
when a feature calls g.rpc.register('rpc_service_id') or when a feature
calls g.rpc.call('rpc_service_id')? It sounds like it used when a feature
registers a service id.
What I am trying to do is get a list of all the rpc services that a gadget
could possibly call. This will be the list of allowed rpc services a
gadget is allowed to call inside a container. If a gadget tries to call a
service not in this list than the call will be "blocked". I was going to
use exports with the type="rpc" to export any rpc services CALLED from
within a feature's JS and then get all the exports with type="rpc" for
each feature a gadget requires in order to generate that list, but that
doesn't seem like that is the intent of exports with the type="rpc".
Sounds like we may need another export type to export the rpc services a
feature calls, would you agree?
-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: Andrew E Davis <andrew_e_davis%ib...@notesdev.ibm.com>, Paul
Lindner <lind...@inuus.com>, dev@shindig.apache.org
Date: 08/23/2011 09:36 PM
Subject: Re: Securing RPC
When you say export, do you mean the JS symbol name or the service ID
registered by g.rpc.register(...)?
I'm assuming the latter based on context... the implemented strategy is to
export when the feature registers it. Am I understanding that your ask is
to
register lazily, only upon the first call? If so, you should be able to
achieve this through use of the default handler, registerDefault(...) no?
-j
On Tue, Aug 23, 2011 at 6:32 PM, Ryan J Baxter <rjbax...@us.ibm.com>
wrote:
> 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<
http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
>
>
>
>
> 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
> > >>
> > >>
> >
> >
> >
>
>
>
