For OpenSocial gadgets, OpenSocial containers are necessary to hold users' data (friends, profile, ...). In Javascript API, class opensocial.DataRequest can be used to get users' data from the container which renders the gadget.
But to integrate users' data from third-party OpenSocial containers, some additional steps are needed. opensocial.DataRequest does not allow gadget developers to specify which OpenSocial container would be used to serve the data. Also the gadgets can not send requests directly to third-party containers because of Same-Origin policy imposed by browsers.
Method gadgets.io.makeRequest can be used to send arbitrary HTTP GET/POST requests. These requests are sent to the original container first. The original container does some processing and relays the requests to the destination address.
http://code.google.com/apis/opensocial/docs/0.8/reference/gadgets/#gadgets.io.makeRequest
http://code.google.com/apis/opensocial/articles/makerequest-0.8.html
http://code.google.com/apis/gadgets/docs/remote-content.html
Both REST and RPC protocol specifications requires that compliant containers must be OAuth service provider:
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol (Section 4)
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-protocol
Also I found OAuth Consumer Request 1.0 Draft 1 (hosted at googlecode, not oauth.net) which standardizes two-legged authorization process without a User involvement. It is useful in server-to-server interaction.
How to use OAuth in gadgets
http://code.google.com/apis/gadgets/docs/oauth.html (Very useful)
http://sites.google.com/site/oauthgoog/oauth-proxy/social-oauthproxy
OpenSocial container list:
http://wiki.opensocial.org/index.php?title=Main_Page#Container_Information
Extensions:
Also, I found many OAuth extension drafts which are not listed in OAuth.net. I guess these extensions are implemented in Shindig and evaluated.
http://oauth.googlecode.com/svn/spec/ext/
Posts
No comments:
Post a Comment