>
> Gotcha. That's a bit unfortunate. As far as I can tell, it would
> imply that an application that wanted to communicate with a backing
> store (other than the SPI-provided persistence API) would need to
> proxy web requests ("validate this is a legal scrabble move") via the
> container, or would need to resort to JSONP-style stuff.
You are correct here. As far as I understand, each container defines
it own gadget-host; which might be either
gmodules.com (or osmodules.com, or something probably provided by google),
or the larger container sites may implement their own module server (google
is in the process of opensourcing their implementation, so this will
probably be used by most).
The gadget server has several tasks, one of which would be to proxy
ajax-requests
(probably after some sort of validation); it is ultimately up to the
gadget server owner to decide what kind of validation is needed,
however I would think that anything DOS-attacks/spam runs is allowed
on most gadget servers. I imagine that even
the calls to the container-site are proxied through this server in most
implementations.
Note that "proxying" here is mostly "relaying", not as much "caching".
If you don't want to use the gadget server (because e.g. the information is
privacy-sensitive), you could either use JSONP to retrieve and iframes to
send data, or flash.
Even so, I'm a bit puzzled as to how sandboxing works.
>
> To avoid the obvious cross-domain scripting attacks, you'd want to
> make sure that the social gadget was loaded via an IFRAME, and that
> IFRAME was hosted on a different domain (the "gadget host") than your
> containing page's content (the "container host").
>
> I guess in that case, my "gadget host" provides the SPI. I play with
> domains suffixes and cookies in such a way that the gadget content
> can use the container's cookie to glean information about the
> identity of the "viewer", but still can't reach out of the IFRAME.
> The SPI turns into web requests back to the gadget host, which
> presumably can access all of my social network's information.
>
> Am I understanding this correctly?
Mostly, yes. How the viewer/owner-information is passed to the opensocial
framework running in the iframe is up to individual implementation (but
passing some sort of token though the url seems the most logical)
Yes, this makes sense, but it seems like this is a performance
> optimization.
Caja is better for performance, but it will also allow better
interaction between gadget and container. At
this moment, the gadget-code in the container has the same information as
the opensocial framework running in the
iframe. So it's not possible to know whether any call coming from
within the iframe is authentic opensocial. Take the case where an
application exposes a button "install on my profile". When the button
(residing withing the iframe) is clicked, a call is made to the
opensocial js, which in case makes a call to the container to copy the
application. But how can the container know the onclick event on the
button wasn't triggered by javascript, or that there even
was a button in the first place. At this moment, the best that can be
done to marshal javascript calls between the application and trusted
code (running on the container site) is altering the target-part
(after the #) of the iframe URL, which is less than fun if you have a
lot of data to transfer...
But I'm still a bit stumped as to, say, how Scrabulous will get
> implemented as an HTML content-type. (I mean, I can see how they'd
> just resort to egregious hackery to do so, but...it seems like a lot
> of gadgets will want to interact with some other service that's
> hosted somewhere else.)
As I mentioned before, there will/should be proxying. Another solution
would be to have your whole gadget be an iframe itself, and there load the
pages you want. The problem there is that these pages cannot communicate
with the opensocial namespace that resides a layer higher, unless you build
an interface to talk over that iframe layer.
So,
basically, the problem is you can only talk to one host using ajax.
This can either be your own host, or the container host, or some proxy
that allows you to talk to both. The latter is the opensocial
approach.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
