[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.


----- 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      
                                       <Gregory.Murray at sun.com>,           
             06/14/2007 10:29          <interop at openajax.org>,             
             PM                        <communicationshub at openajax.org>    
                                       Re: [OpenAjaxInterop] The 5th       
             Please respond to         Problematic Use Case and Push Back  
                "Kris Zyp"             Call time by Two Hours              
             <kriszyp at xucia.co                                             

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:
 ----- 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.


 Inactive hide details for Greg Murray <Gregory.Murray at Sun.COM>Greg Murray
 <Gregory.Murray at Sun.COM>

                         Murray <                                          
                         Murray at S                                          
                         un.COM>                                        To 
                         Sent by:                                          
                         Gregory.           Jon Ferraiolo/Menlo            
                         Murray at S           Park/IBM at IBMUS                 
                         06/14/20           interop at openajax.org,          
                         07 04:44           communicationshub at openajax.org 
                                            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

             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

             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.




             Greg Murray <Gregory.Murray at Sun.COM>
              Greg Murray <                                                
              Gregory.Murray at Sun.COM                                       
              Sent by:               <ecblank.gif>                         
              Gregory.Murray at Sun.COM                                    To 
              06/14/2007 02:43 PM                 Coach Wei <              
                                                  coach at nexaweb.com>       
                                                  Greg Wilkins <           
                                                  gregw at webtide.com>, Jon  
                                                  Park/IBM at IBMUS,          
                                                  interop at openajax.org,    
                                                  communicationshub at openaj 
                                                  Re: [OpenAjaxInterop]    
                                                  The 5th Problematic Use  
                                                  Case and Push Back Call  
                                                  time by Two Hours        

             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
             > 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
             > 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
             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
             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
             events that did not generate in the
             current context and use regular expressions for wildcards with
             liseners we want to pick up these

             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
             that extensive.


             interop mailing list
             interop at openajax.org

 interop mailing list
 interop at openajax.org
-------------- 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