Thanks chris for your quick and clear response. The requirements arise from the fact that I want to set up a shindig on my site, and provide social api for some developers to write applications which can be embedded on my site, but the target developers perfer to use restful like api rather than javascript api. And supporting 3 legged oauth is not my goal.
My initial idea is do something like securitytoken. Given the gadget domain is www.exampleapp.com, I generate a one time token(st) which includes user id, app id e.g(shindig has already done this), and pass the st as parameter to application's home server, the url of iframe may be http://www.exampleapp.com?st=***&other parameters then the application's home server can use that one time token to exchange a long lived token(may be 30 mins or more) and get user's data via restful api, authenticated by the long token. Actually it's pretty much like the authentication process of gadget javascript api. I know there may be some flaws of this approach, can you shed some light on it? Thanks very much again:) On Wed, Jan 21, 2009 at 10:15 PM, Chris Chabot <[email protected]> wrote: > Hi Cai, > > That completely depends on the situation. > > If your building both parts, there is nothing limiting you from making RPC > calls (of any kind) to a different back-end, so taking social requests and > proxying them to a different OpenSocial back-end is quite possible as long > as you implement something that does that relaying. (there's no standard > solution for this though) > > If you want to talk to someone else's OpenSocial back-end, then you need to > talk to that other party to see if they will allow this, and what kind of > authentication is required to do so . > > The REST end-point is intended to allow a gadget to talk to it (using a > short lived security token), a remote server to talk to it on behalf of a > gadget that a user has installed (2 legged oauth), or on behalf of a user > (without a gadget being involved) through 3 legged oauth, where the user has > to grant permission on the social site before said communications can take > place. > > None of those solutions fit your requirements, so you would have to agree on > a different way of getting access to their REST end-points. > > On Wed, Jan 21, 2009 at 9:43 AM, sonic <[email protected]> wrote: > >> hi opensocial experts, >> >> I understand gadget domain should be a different domain other than the >> container domain for some security reason, and gadget domain should >> still be under container's control. >> I am just wondering if it's possible to host a 'gadget'(I just borrow >> this word) on a third party domain, then the gadget home server can >> communicate with the container's server via restful api? Is it a >> standard way to use shindig? >> >> -- >> Cai Jian >> > -- Cai Jian
