BTW I did implement storing tokens in the database (in rave-shindig) On 1 August 2011 22:18, Jasha Joachimsthal <[email protected]>wrote:
> Hi Jesse, > > Indeed I got a stuck in handling the security tokens in Shindig, noticed > some changes in the Shindig trunk for oAuth and decided to focus on storing > the tokens in the db (which I committed just before I went on holiday). The > (working) code I had was too dirty (hacks & hard coded tokens) to commit. > This week I won't have time to work on it so go ahead :) > > Jasha > > > > On 1 August 2011 22:13, Ciancetta, Jesse E. <[email protected]> wrote: > >> Hi Jasha, >> >> I was thinking of spending some time trying to get Rave generated security >> tokens working with OpenSocial gadgets -- I know you had done some work on >> this already but ended up blocked awaiting responses from devs on the >> shindig list regarding how to integrate custom tokens with the common >> container. >> >> Would you mind if I go ahead and pick that work up? I'm referring only to >> generating security tokens on the Rave side and getting the common container >> to use them -- not any of the OAuth work that I know you already have well >> underway. >> >> Thanks, >> >> --Jesse >> >> >-----Original Message----- >> >From: Jasha Joachimsthal [mailto:[email protected]] >> >Sent: Wednesday, June 29, 2011 3:19 AM >> >To: [email protected] >> >Subject: Re: 3-legged oAuth >> > >> >On 28 June 2011 21:12, Ciancetta, Jesse E. <[email protected]> wrote: >> > >> >> >> >> > >> >> >We're lost now in the magic that happens inside >> container.navigateGadget >> >> so >> >> >I've just posted a question on the Shindig-dev list how we can get an >> >> >iframeUrl with a valid security token. >> >> >> >> I think it may be interesting to figure out how to get the Shindig >> metadata >> >> call to return us a proper security token in the response, but I'm not >> sure >> >> it is actually the we want to approach the problem. Since we (Rave) >> are >> >> going to be a full standalone container with server side components >> capable >> >> of generating the security tokens ourselves, I think that's actually >> the way >> >> we want to go. I had wired in the Shindig common container code >> initially >> >> "out of the box" just so we could get things working, but had intended >> to go >> >> back and make changes so that we could do things like set security >> tokens >> >> and user preferences from the Rave side instead of having to rely on >> >> metadata calls to Shindig from the client browser for that work -- I >> just >> >> haven't had a chance to get back to it yet. >> >> >> > >> >In Shindig 2 it was possible to call container.addGadget with a gadget >> >object that contains the security token. In Shindig 3 this method seems >> to >> >be gone. In the way we're rendering the gadgets I haven't been able to >> set >> >the security token from our side. I agree with you that Rave should >> provide >> >the token and should not rely on the container (Shindig) for that. I'll >> try >> >to find out where we can override this behaviour. >> > >> > >> > >> >> I think the confusion (at least what seems somewhat confusing to me) is >> >> what the common container is really targeted to do. I think it's >> supposed >> >> to allow any web page to script include the common container JS code >> and >> >> then start embedding gadgets without having to stand up any other >> >> infrastructure (aside from the Shindig server). But that comes at a >> cost -- >> >> using the common container as is (and as we do now) means that: >> >> >> >> ** You have to run the your container code (Rave in our case) and >> Shindig >> >> on the same host/port to allow the ajax call that the common container >> >makes >> >> back to Shindig to fetch gadget metadata succeed (otherwise you'll get >> >> security exceptions for making cross site Ajax calls). The only way >> around >> >> that is to stand up some kind of server side proxy on your container >> domain >> >> to proxy the ajax call back to Shindig. >> >> >> >> ** You have to enable authentication in front of Shindig (at least for >> the >> >> metadata calls) and SSO between your container and Shindig so that the >> >> endpoint to generate a security token is secure. If it were wide open >> I >> >> could generate iframe urls with security tokens embedded in them for >> >> whatever users I want. >> >> >> >> ** Common container has to make the ajax call to fetch gadget metadata >> on >> >> every page render -- and with a full container implementation (like >> Rave) >> >> this really shouldn't be required. We should be able to cache whatever >> >> metadata we need on the server side and send it down to the browser >> with >> >our >> >> page response, and we should be able to use it to prime the common >> >> container's metadata cache. I've already got some of that plumbing in >> place >> >> -- so if you look at the source of a rendered Rave page you'll see the >> >> "metadata" property on the JS object we push onto the widgets array is >> >> populated with the results of a server-side call to the Shindig >> metadata >> >> service. I think that data could then be used to prime the common >> >container >> >> metadata cache to eliminate the need to make that call on every request >> - >> >> see the TODO notes in the rave_opensocial.js for more information on >> how >> >> that might be done. >> >> >> > >> >Ah, I wondered why the metadata were on the JS object (as a result from >> the >> >OpensocialWidgetRenderer) but not being used. >> > >> > >> >> So I think in the end we want to use the common container code as a >> basis >> >> to take advantage of whatever existing/common/sharable functionality we >> >can, >> >> but we'll also need to override some of its default behavior with our >> own >> >> code too. >> >> >> >> I wish I could dig in deeper right now to help more with this piece but >> I'm >> >> tied up with other work at the moment. Hopefully this makes sense and >> >helps >> >> though. Does this approach sound right to you guys? >> >> >> > >> >It does but I guess it won't be finished in the near future. We first >> wanted >> >to have a working gadget with oAuth in any way on our local machines and >> >then start adding functionality in Rave in a proper way. We've got a >> >'working' gadget so now I can start looking where the hacks can be >> replaced >> >by proper overrides or look for alternatives. >> > >> >Jasha >> > >
