Thanks Kevin -- your comments got me going in the right direction. I was testing things out using FireBug's console.log function, and apparently console.log was letting me get away with things that I'm not able to otherwise. I was able to use console.log to log out the location of another cross-domain iframe on the page, but trying to do something else with it like send the location to an alert box threw a security exception.
The only other thing I'm still not clear on is what's happening on the Shindig side to enforce locked-domain -- I think I understand two out of the three methods in the Shindig LockedDomainService interface: gadgetCanRender -- I think this method is here to keep gadgets from doing things like dynamically adding a child iframe to themselves to render on another gadgets locked domain (since the locked domains are well known since they are a hash of the gadget URL). getLockedDomainForGadget -- Self explanatory... isSafeForOpenProxy -- This one I havent quite figure out yet. I plan to spend some time next week trying to understand what the default HashLockedDomainService is doing here, but if someone can say a few quick words in the meantime about what this method is for, I'd appreciate it... Thanks! --Jesse On Wed, Dec 9, 2009 at 2:53 PM, Kevin Brown <[email protected]> wrote: > On Fri, Dec 4, 2009 at 7: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? > > > > 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 <[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! > > > > > >
