[OpenAjaxSecurity] Cross-domain discussion within other committees
Jon Ferraiolo
jferrai at us.ibm.com
Fri Jun 15 08:06:41 PDT 2007
FYI - This thread mentions Subspace (from Stanford and MS), Dojo Iframe
Proxy, and how jMaki handles cross-frame communications.
Jon
----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 06/15/2007 08:05 AM
-----
"Kris Zyp"
<kriszyp at xucia.co
m> To
Sent by: Kris Zyp "Greg Murray"
<kriszyp at gmail.co <Gregory.Murray at sun.com>, Jon
m> Ferraiolo/Menlo Park/IBM at IBMUS
cc
<Gregory.Murray at sun.com>,
06/14/2007 10:29 <interop at openajax.org>,
PM <communicationshub at openajax.org>
Subject
Re: [OpenAjaxInterop] The 5th
Please respond to Problematic Use Case and Push Back
"Kris Zyp" Call time by Two Hours
<kriszyp at xucia.co
m>
One other important approach to cross-domain communication is an
alternative iframe proxying technique called subspace that you may not have
looked at, and I believe is different than any of the ones mentioned. This
a very sophisticated technique worth reading about that combines browser
cross-domain requests with a level of sandboxing:
http://www2007.org/program/paper.php?id=801
Kris
----- Original Message -----
From: Jon Ferraiolo
To: Greg Murray
Cc: Gregory.Murray at sun.com ; interop at openajax.org ;
communicationshub at openajax.org
Sent: Thursday, June 14, 2007 5:19 PM
Subject: Re: [OpenAjaxInterop] The 5th Problematic Use Case and Push Back
Call time by Two Hours
OK, thanks. Now I am confident we have covered the subject completely.
Jon
Inactive hide details for Greg Murray <Gregory.Murray at Sun.COM>Greg Murray
<Gregory.Murray at Sun.COM>
Greg
Murray <
Gregory.
Murray at S
un.COM> To
Sent by:
Gregory. Jon Ferraiolo/Menlo
Murray at S Park/IBM at IBMUS
un.COM
cc
06/14/20 interop at openajax.org,
07 04:44 communicationshub at openajax.org
PM
Subject
Re: [OpenAjaxInterop] The 5th
Problematic Use Case and Push
Back Call time by Two Hours
Hi Jon,
On Jun 14, 2007, at 3:58 PM, Jon Ferraiolo wrote:
Hi Greg,
I wanted to make sure that we are talking the same language
here.
My understanding is that the main usage scenario with jMaki is
in conjunction with a server technology such as JSF. As a
result, if you use a cross-domain feature such as Yahoo Maps
in jMaki within an iframe, then the server is performing proxy
services for you, such that from the browser's perspective the
iframe and the main document come from the same domain, and
therefore it is possible for the main frame and the iframe to
talk with each other.
I believe one part of the 5th use case is when there is no
server proxy involved, just some HTML that has the main frame
coming from AAA.org and an iframe coming from BBB.org. In this
scenario, the browser prevents scripts within the main frame
from accessing the DOM of the iframe and vice versa.
Aww this is what you are referring to. We can't handle this in jMaki and
to be honest I would rather avoid it. We recommend our users use a server
side proxy for all external domain communication.
Doug Crockford has made a proposal for JSON-based
communication in such scenarios as part of his <module>
proposal (http://json.org/module.html ), Dojo has found a
loophole in today's browsers that allow cross-frame
communication with its iframe proxy feature (
http://dojotoolkit.org/node/87 ).
I have looked at both of these proposals and both are promising. The dojo
approach requires code on both sides for the proxies to work if I remember
correctly.
So, does jMaki support client-side cross-domain communication
between frames without the use of server proxies? If so, does
it use the Dojo technique or something else?
We only recommend cross domain communication using a server proxy. In
almost all cases the communication is with RESTful XML services.
We can interact with JSONP calls but there are limitations/risks with this
approach unless both sides really trust each other and there is a means to
filter out untrusted requests. I did a bit of work/re-search in this area
and have blogged on it if anyone is interested.
-GregM
Thanks.
Jon
<graycol.gif>
Greg Murray <Gregory.Murray at Sun.COM>
Greg Murray <
Gregory.Murray at Sun.COM
>
Sent by: <ecblank.gif>
Gregory.Murray at Sun.COM To
<ecblank.gif>
06/14/2007 02:43 PM Coach Wei <
coach at nexaweb.com>
<ecblank.gif>
cc
<ecblank.gif>
Greg Wilkins <
gregw at webtide.com>, Jon
Ferraiolo/Menlo
Park/IBM at IBMUS,
interop at openajax.org,
communicationshub at openaj
ax.org
<ecblank.gif>
Subject
<ecblank.gif>
Re: [OpenAjaxInterop]
The 5th Problematic Use
Case and Push Back Call
time by Two Hours
<ecblank.gif>
<ecblank.gif>
Hi Coach,
I've commented in line on the cross frame communication:
On Jun 14, 2007, at 1:00 PM, Coach Wei wrote:
> I added the 5th use case as we talked during the last
conference call:
> (http://www.openajax.org/member/wiki/Problem_Defintion_-
> _CommunicationTF
> )
>
> 5. Cross frame communications
> Scenario: An Ajax application that is composed of multiple
iframe (or
> frame) components and these iframe components need to
communicate with
> the parent frame or each other;
> Issue: If all iframe components and the parent frame use
OpenAjax
> CommunicationHub, they should be able to communicate with
each other
> automatically (if they all come from the same domain);
However, if the
> come from different domain, the cross-site communication is
not
> allowed
> as a security constraint.
> Comment: Not sure whether we should provide a solution here.
We should
> talk to the Security Task Force on the one side. On the
other side,
> take
> a look at Dojo etc to see whether their techniques are
suitable here.
>
Cross frame communication using a communication bus is
something that
is possible and
we use extensively jMaki.
As far as security is concerned these frames are those created
by
widgets or layout containers
that generally contain other widgets that were defined using a
secondary call to a resource
within the same application.
The best examples we have are Yahoo / Google Maps which both
need to
be loaded into an
iframe if they are contained within a tabbed view or loaded
dynamically. We still want to be able
to interact with the map and drop markers on the map but would
not be
able to do so easily without
our publish and subscribe.
In jMaki we publish to the subscribers in the current context
and
then look for child iframes within that
context and for parent frames. If those parent frames contain
a jmaki
object we re-publish events both
up and down by default.
One problem you will run into is that events may get picked up
2x if
you have similar application code
used in both frames. For this purpose we prepend "/global" to
all
events that did not generate in the
current context and use regular expressions for wildcards with
the
liseners we want to pick up these
events.
The cross frame communication using pub/sub has been very
useful for
us in jMaki and I think it
would be very useful in the hub. The code required to do it
isn't
that extensive.
-GregM
<graycol.gif>
<pic03865.gif>
<ecblank.gif>
_______________________________________________
interop mailing list
interop at openajax.org
http://openajax.org/mailman/listinfo/interop
_______________________________________________
interop mailing list
interop at openajax.org
http://openajax.org/mailman/listinfo/interop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070615/9c5346c9/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic29484.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070615/9c5346c9/attachment-0004.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070615/9c5346c9/attachment-0005.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 21036392.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070615/9c5346c9/attachment-0006.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 21636166.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070615/9c5346c9/attachment-0007.gif
More information about the security
mailing list