OK, I hadn't though about that. On the one hand I wonder what value a gadget
has that can only be used by a limited number of viewers (since as I
understand it the whole idea is to host the gadget on a public profile, how
many people would like to have a gadget there that the majority of visitors
cannot see nor use?). But lets just
take this case as a theoretical exercise.
The first issue would be: to what extend do you not trust the container. I
can imagine that, lets say, a banking application that allows you to
transfer money to your friends, would need some extra security. The good
news here is that the iframe-barrier works in two directions. The gadget
cannot access anything on the container-page, nor can the container access
anything in within the iframe. The bad news is that
the opensocial namespace javascript
is included, and this is a security risk. So, by definition, your gadget
cannot both be secure from the container, and include the opensocial
namespace *), without an additional layer of security. This additional
layer could be Caja (although I'm not sure it's mature enough yet, nor
whether opensocial will run on it), or an extra iframe.
I'd say the last option is the best one at this moment. You'd then have
something like this:
<html> container page
<iframe src="
http://www.osmodules.com/mymodule.php?src=http://www.securemodule.com/module.xml#token=123456
">
<script src="http://www.orkut.com/opensocial.js";></script>
<iframe src="http://www.securemodule.com/mymodule.php";> ........
The code in the inner iframe comes directly from securemodule, and cannot
have been tampered with. No javascript from the container can access the
DOM or variables inside the inner iframe (since it's from another
domain). The only question now is how to do opensocial calls. I would
think you'd need some library on both sides of the inner iframe, that
marshal calls through the #-portion of the iframe url (since I think
that is the only part that can be accessed from both within and
outside the iframe, and won't trigger a reload (on most browsers, that
is)). The bad news is, this is not easy to do, the good news is that
you (someone) only need to do it once, and the whole world can then
use that method.
*) This is to say: unless you host your own opensocial.js (which you
manually checked for any secirity issues), in which case you either need to
use the (standarized) data-api, or be subject to unannounced changes in the
container implementations
On 12/4/07, Chris Waterson <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 4, 3:44 am, "Reinoud Elhorst" <[EMAIL PROTECTED]> wrote:
>
> > 3) You haven't made a case why you need url contenttype. If you need
> pages
> > rendered on some server, just retrieve them using ajax and display them
>
> Network topology.
>
> The social network I'm building has some gadgets I want to host behind
> a firewall. Someone who is behind the firewall can access the gadget;
> someone who isn't, can't. For example, I'd like to allow a gadget
> that can access some resource that a corporation wants to guard.
> (Corporate calendar, email system, whatever.)
>
> I realize there are ways to hack around this (like creating a public
> proxy server that can reach behind the firewall, or using "JSONP"
> <script> tag fetches from the UA to defeat cross-domain restrictions),
> but those have security consequences. Namely, let's say we consider
> the gadget to be "trusted", but the container to be "untrusted".
> Since the gadget is trusted, we assume that it won't attempt to
> compromise security and leak information. Since the container is not
> trusted, we cannot make the same assumption.
>
> Anyway, I'm just trying to get a sense of what folks are thinking in
> this direction: I realize I'm going to have to invent my own solution
> for a while. I just want that solution to be in the same general
> vicinity as the finalized OpenSocial. :)
>
> thanks!
> chris
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Implementing OpenSocial Containers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/opensocial-container?hl=en
-~----------~----~----~----~------~----~------~--~---
