On 1/30/08, 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 :) >
I'm all the way with you, however I wouldn't want to store the bit that some gadget has access to the viewer on my server. This would only be useful if we want to make the access persistent, however I think that I'd just want to allow access for that one session (as long as the user stays on the same container page, possibly persist it when moving to another view of the same gadget). I'd rather see that there are two security tokens, one always available to the gadget (which the gadget always sends with any makeRequest, and which is checked by the gadget server to see which gadget it is, and who are the viewer and owner). The second is only available to the gadget when it has access to the viewer information. So this can either be included in the initial #-part of the iframe url (in case the business rules decide that permission is granted from the start), or is sent to the gadget through ifpc after a successful opensocial.requestPermission: - the requestPermission would check for the second security token to be present, if so, call callback right away - if the second token is not present, send an ifpc to the container-page - the container page shows a popup (or moves away to another page) - if the request is granted, the container page does an ifpc to the gadget (it would need this anyway to initiate the callback), with the second security token. For any request the gadget makes (through the gadget server, either by an opensocial dataRequest, or a gadgets.io.makeRequest), both tokens are sent (assuming that the second token is present, else only the first is sent). By checking the second token, the gadget server knows whether the gadget has access to the viewer without duplicating any of the container's business logic (which is quite a big plus if the container and gadget server are in different languages!). By checking the second token, the container knows that the permission was granted, and doesn't have do re-do it's own business logic, or inquire any persistent storage. Above description with two security tokens, could also be replaced by a single token, that changes value. The basis is having 3 states: No access at all (should not occur in "friendly" gadgets), access to all but viewer information, access to all. Other permissions that persist along one session, could be encoded in a similar way, although I believe that only the "viewer" permission has the extra benefit of being useful to the gadget server as such, because of the phone home. Reinoud
