When you have a page with 2 gadgets on it and those gadgets both have the same domain, those gadgets can affect eachother. One gadget could insert code or change the look of the other for example. So it's important to render each gadget on a seperate subdomain when you allow 3rd party gadgets.
On Wed, Sep 21, 2011 at 12:32 AM, Dan Dumont <[email protected]> wrote: > I'm trying to understand a bit more about the locked domain feature > implementation in shindig, if someone familiar with the process could take > some time to answer these questions, I'd appreciate it. > > Most of the checking seems to happen around 2 classes, an enum defined in > UriStatus and the implementation of DefaultIframeUriManager. > validateRenderingUri. What I'm not finding is anything keying off of the > status to ensure that statuses of INVALID_DOMAINare not allowed to render. > Seems like the status request is mostly used for caching based on > versioning or lack of versioning. When I search for references for > INVALID_DOMAINthe only thing that really uses it to prevent activity is > ProxyUriBase.translateStatusRefresh and that happens much later after the > render. > > So here are my questions: > > What are we really trying to protect against with locked domains? > Is there a concern in allowing a gadget to render on the domain of another > locked-domain gadget? (the check is there in shindig right now but I can't > find anything that's enforcing the status that's returned for render > calls) > Is the render an important thing to protect, or is it mostly for requests > through the proxy? > > > > >
