* bump * Any feedback at all on this thread would be appreciated...
Thanks! --Jesse On Mon, Dec 7, 2009 at 4:48 PM, Jesse <[email protected]> wrote: > 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! >>> >> >> >
