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
