On Fri, Dec 4, 2009 at 7:46 AM, Jesse <jss9...@gmail.com> 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? >
If you have locked domain implemented correctly, you can't read the location property. It's write-only on all major browsers that implement the same origin policy (that is to say, all browsers that anyone uses). If you've found an instance where you can read the property, it's either a browser bug, or you aren't actually rendering each gadget on a unique host. Make sure that each domain is on a unique host name, and that the gadgets aren't modifying the value of document.domain. > > 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 <jss9...@gmail.com> 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! > > >