(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
-~----------~----~----~----~------~----~------~--~---
