I'm thinking the answer WRT the security token is to use a short lived token on the gagdet URL and swap that out for a longer lived token on the Shindig side -- but it still seems that there would be at least some small window on page load where the short lived token could still be sniffed/used by another gadget on the page for evil.
As for the RPC token -- is that used for anything sensitive? Do I need to be concerned about it being sniffed by other gadgets on the page? And finally -- I'm still trying to understand what I need to do on the Shindig side WRT locked domain support. I see options in the shindig config file to enable locked domain, but it seems like most of the work would be on the container side in generating the iframe url's on unique domains... Please see the rest of this thread for more details. Any feedback at all on this would be appreciated... Thanks! --Jesse On Fri, Dec 4, 2009 at 10:46 AM, Jesse <[email protected]> wrote: > I've experimented a bit more with locked domain by just setting up my > container to prepend a counter to the iframe url for each gadget -- so I end > up with iframe urls which look something like: > > 1.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&... > 2.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&... > 3.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&... > ... > > (I realize that the urls should stay consistent across page renders for the > same gadget, but for testing purposes I just wanted to get the gadgets on > unique domains) > > Everything seems to work just fine with this setup, and I do indeed see > additional sandboxing happening in the browser. I tested this by doing some > experimentation in FireFox using FireBug -- before implementing the locked > domain changes all of these statements in FireBug execute successfully: > > cd($("remote_iframe_0").contentWindow); //change FireBug's context to the > window of one of the gadgets > console.log(document.location); //make sure the context is now what I > think it should be > var otherWindow = window.parent.frames["remote_iframe_1"]; //grab a > reference to the window of another gadget > console.log(otherWindow.location); //log its location to be sure I have a > hold of the iframe I think I do > console.log(otherWindow.document.getElementById('someElement').textContent); > //log out the content of an element in the other gadget > > and as soon as I implement locked domain as described above, the last > statement fails with a security exception (as expected). > > But I'm still left with a few questions... > > 1) Even with the gadgets rendering on their own domains, I can still get to > the location property of other gadgets on the page, which means I can parse > out things like the security tokens and rpc tokens -- doesn’t that mean one > gadget can still spoof another? How do other containers handle this? > > 2) I'm still trying to understand what all the locked domain code in > Shindig is for... I can see how some of it would be useful in my container > (like the logic in HashLockedDomainService that generates the iframe url > based on a hash of the gadget url) -- so is that why it’s there? To be use > on the container side? But then I also see methods in the > LockedDomainService interface that definitely seem Shindig specific like > isSafeForOpenProxy and gadgetCanRender, so I'm sure there must be more to it > that I'm not understanding... I've spent a bunch of time digging in the > Shindig codebase and searching through the mailing list looking for tidbits > but haven’t made much progress so far... > > Any help or pointers would be greatly appreciated! > On Thu, Dec 3, 2009 at 9:55 AM, jss9920 <[email protected]> wrote: > >> I would like to start rendering my gadgets on unique locked domains but am >> getting a bit confused about where to start... >> >> Since the container generates the gadget iframe urls, it would seem that >> implementing locked domain would be a container side affair, but I see >> configuration options for locked domain support in the shindig container.js >> file and I also see associated Java classes that do a lot of locked domain >> work in the Shindig codebase (Java Shindig 1.0 release)... >> >> So is there actually work that needs to be done on both the container side >> and the Shindig side to enable locked domain gadgets? >> >> Any pointers on how to get started (even high level) would be helpful and >> much appreciated. >> >> Thanks! >> > >
