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!
>
