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 :)
