On Fri, Dec 11, 2009 at 12:51 PM, Jesse <[email protected]> wrote: > 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... >
"open proxy" requests refer to requests that pass through /gadgets/proxy. These resources do not need to be served on the same domain as the gadget itself, and in fact it is a big performance win for them to be served off of some small set of static hosts (a typical pattern might be www[0...n]. gadgethost.com). IMO most of this should be enforced with filters rather than in the servlets, but the argument against this was that it's too easy to screw up. > > 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! > > > > > > > > > >
