Kevin...... remember? That day I had asked you how to provide site's data to the gadget? Can u please explain how to do it? Which files I have to edit? and info like that........
On Jan 30, 2008 4:18 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > 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. > -- Akash Manohar [EMAIL PROTECTED]
