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 >
