1) This has more to do with the DATA-api than the javascript api (or url content type). As far as I know there is no timepath for the data API yet, other than "soon". 2) This would only work (as far as I understand) if the js and data api shared the same accesstokens in some way.
3) You haven't made a case why you need url contenttype. If you need pages rendered on some server, just retrieve them using ajax and display them So, I wouldn't wait for this and just start building the gadget as suggested in 3) On 12/1/07, Chris Waterson <[EMAIL PROTECTED]> wrote: > > > (Long, sorry.) > > I realize ([1], [2]) that URL content-type gadgets and the web API may > take some time to solidify. However, having these things working is > pretty important for my container, and I'd like to at least start > moving in the right direction. I would love feedback on how close to > reality (or, future reality) I'm coming. It sounds like a lot of > people are discussing this sort of stuff, but I'm probably just not in > the right places to be hearing it. > > Below is a stab at how I'd use OAuth to deal with running a "URL" > content-type social gadget. A URL content-type gadget is one that is > served from a domain outside the container's gadget infrastructure, > and therefore is beholden to cross-domain scripting restrictions. I > want the gadget to be able to interact with my social network, but I > don't want to give it carte blanche to access my users' information. > So it needs a way to "masquerade" as a user, but only with that user's > permission. > > Note that this is somewhat different that [3], wherein an HTML-type > gadget (namely, one that is rendered from the container's > infrastructure) needs to proxy a request back to an application > server. > > So, for starters, let's assume that the gadget developer has > registered their gadget with the container site. This includes: > > * Specifying the Google module definition. > > * Setting (or being given) an OAuth "Consumer Key" and "Consumer > Secret". > > Now, Vinnie (the "viewer") comes along and opens a page in the > container social networking site that contains the social gadget in > the context of some other user Ollie's (the "owner") page. > > What happens? > > 1. The container renders the content page, which includes an IFRAME > that loads the gadget from the gadget's URL as specified in its > module file. > > The URL query parameters contain: > > * Vinnie's identity within the container social network (maybe > it's an OpenID, maybe it's just a UID). > > * Information that the gadget needs to initialize itself, such > as the instance of the gadget, the fact that Ollie owns it, > etc. > > * Information about the containing site. Probably, this is a > URL to some sort of manifest that defines a bunch of access > points that the gadget will need in the below OAuth > interaction. (Yadis [3] springs to mind.) > > Notably, we do *not* pass in any other information about the > Ollie or Vinnie to the gadget. > > At this point, the gadget wants to know information that's stored in > the containing site (Ollie's friends, picture, whatever). That means > it has to go query the container site. Furthermore, we want the > gadget to have no more or less visibility into Ollie's world (or > Vinnie's, for that matter) than Vinnie himself has. > > Enter OAuth, where the gadget is granted a "pass" to masquerade as > Vinnie -- with Vinnie's permission -- for a bit. In this case, the > OAuth "Consumer" is the gadget, and the OAuth "Service Provider" is > the containing social network. So...we begin the OAuth dance: > > 2. The gadget (the Consumer) makes an HTTP request to the > container's "Serivce Provider Request Token URL". This request > contains the gadget's OAuth Consumer Key, and is signed with the > gadget's Consumer Secret. > > 3. The container verifies the signature of the request, and if its > valid, responds with an "Unauthorized Request Token" > > 4. The gadget causes the UA to redirect the IFRAME back to the > container's "Service Provider User Authorization URL". The > redirect includes the "Unauthorized Request Token". > > At this point, we're supposed to ask Vinnie if the gadget is really > allowed to masquerade as him. There are a bunch of UE issues here, > but my guess is that the way I'll deal with this is to have the > "Service Provider User Authorization URL" check Vinnie's cookie, and > if it's valid, claim that Vinnie has consented. > > 5. If Vinnie consents to allow the gadget to masquerade as him, then > we redirect the IFRAME back to the gadget, and indicate that the > Request Token is now kosher. The container probably has to write > down somewhere that the token is now authorized, and it allows > the holder to masquerade as Vinnie. > > 6. The gadget now makes an HTTP request to the container's "Service > Provider Access Token URL" to exchange the Request Token for an > Access Token. The container does exactly that, issuing an access > token that can be used to masquerade as Vinnie, most likely in > some limited sense. > > Now the gadget can use the Access Token along with the container's > OpenSocial web API to do stuff with Ollie's gadget as Vinnie. For > example, > > * If Vinnie is allowed to see Ollie's Person information, then the > gadget can retrieve and render it. > > * If Vinnie is allowed to see Ollie's friends, then the gadget can > retrieve and render Ollie's friends. > > Notably, if Vinnie *can't* do those things, then the gadget can't do > them either. > > Anyway, I'd love feedback on this. I'm kind of grasping at straws > here! > > thanks, > chris > > > [1] > http://feeds.feedburner.com/~r/OpensocialApiBlog/~3/191964788/thoughts-on-implementing-opensocial-for.html > > [2] > http://groups.google.com/group/opensocial-container/browse_thread/thread/95b374ec4f95c8b2 > > [3] > http://opensocialapis.blogspot.com/2007/11/improved-content-fetching-for.html > > [4] http://yadis.org/papers/yadis-v1.0.pdf > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
