On Jan 30, 2008 2:46 PM, Cassie <[EMAIL PROTECTED]> wrote: > On Wed, Jan 30, 2008 at 12:30 PM, Reinoud Elhorst <[EMAIL PROTECTED]> > wrote: > > > On 1/30/08, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > > > > OK, I think the answer to this question is that the container and the > > > gadget server need to collaborate closely. If the gadget server has > > > enough information to validate and decrypt the security token it is > > > already tightly coupled (sharing keys) with the container. They need > > > to have a common understanding of policy as well. > > > > > > There's more than one way to pass that policy information between the > > > container and the gadget server. Depending on how much information > > > there is it might fit into the security token, or you might want to > > > have them share a backend data store that they use to reference > > > policy. > > > > > I think I'm staring to get it. Still, there may be situations that the > > permission to view the viewer information is obtained client side (so > > neither the container nor the gadget server have any knowledge of this) > > though opensocial.requestPermission. I can imagine that in quite some > > implementations, this call will pop up something on the container-page > > (through rpc/ifpc) asking for permission to send viewer data to the > > gadget. > > As I come to think of it, if you don't want to route your opensocial > > dataRequest calls through ifpc to the container page, you're going to > > need > > some extra token there to let the dataRequest call know that permission > > was > > obtained. This same token can (should?) then be used to let the gadget > > server know that the gadget has access to the viewer information. > > > > I'm actually not quite sure on how much of the requestPermission has > > already > > been implemented in shindig; perhaps I'm just stating the status quo > here. > > > We haven't implemented it yet in shindig. I would imagine though that if > you > want to pop up a dialog to the user you would ifpc to the parent page, the > parent page would pop up a dialog and get the users input. You would then > need a server call from that outer page back to your server to store the > bit > in your data storage. Then, the ifpc calls back to the inner iframe with > the > result (if needed). > > You could instead just have that call be a redirect to a new page on your > site and when it completes you would just go back to the original page and > reload all of the gadgets. This is also perfectly spec compliant. > > So either way you either need to navigate the page or use ifpc for > anything > that needs user input (because you can't trust anything that comes from > the > iframe) > > This is slightly different from any calls that just get data from the > server > though. Because you don't need any user input the calls can not be faked > from the users perspective, which means you can call directly back to your > server and do not need any ifpc to the outer container if you use the > special token on the hash. > > Does that makes sense at all or did I just confuse everybody more, lol :)
You can't trust anything from anyone (on your server). It's no more difficult to pretend to be myspace than it is to pretend to be the iframe, so making an ifpc call doesn't really help you any (unless your gadget is only trying to authenticate against the parent site, in which case that's what the GadgetSigner interface is for). Without signing support, authentication of requests is non-existent (unless you're rendering the gadget on your parent domain and letting it access cookies or something). Anything that requires this sort of support must be done as a redirect today.
