On Jan 30, 2008 12:05 AM, Martin Webb <[EMAIL PROTECTED]> wrote: > On 30/01/2008, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > > Real production sites should always render the iframe on a different > > domain > > from the parent site This is critical for security. Without it, none of > > the > > other security solutions matter. > > > > This would be true for 3rd party gadgets - but what about the domain's own > gadgets? For example, http://www.google.com/ig also hosts gadgets for > Google's other applications, e.g. mail, Google reader, Google Calendar, > GGE > etc, etc... For the domain's own gadgets wouldn't they be server from an > iframe on the same domain? This then supports SSO across the apps from > the > same domain?
You could, but currently shindig has no way to discriminate between gadgets from different domains, so there's no way to do this securely without server side changes at this point in time. If you really trust a gadget, you can do whatever you want with it (even inline it without Caja). I think this is valuable functionality, but we need a solution that ensures that only trusted gadgets can be rendered on the domain. This dovetails into an implementation of locked domain. Ideally a solution like this wouldn't just require the same domain, but that the gadget be served from the server itself (in the file system or perhaps as a resource file). This eliminates potential DNS related exploits as well. If so, does this imply there needs to be two instances of ifpc_relay.html > file - one for 3rd party gadgets that is not hosted on the main domain but > somewhere else, and one for the domain's own gadgets? If it's the same domain, ifpc_relay isn't necessary at all; either the gadget could modify the parent page directly, or gadgets.rpc could be implemented in such a way that it was domain aware and just used ifpc when it was a third party gadget. The latter is recommended, and it's what we'll need anyway to support inline cajoled gadgets in the near future.
