Re: Opening a message tunnel to multiple pages without nested iframes

[Patrick]

In looking at this a little bit more seems that the Hash transport requires the target url.  However, postMessage does not.  

Does NameTransport, FlashTransport or FrameElementTransport have this requirements as well?  If not, I am wondering, if HashTransport is not needed we could setup a more traditional open communication between a domain instead of a static url in an iframe.

I have another demo setup that may be a more desirable fallback than HashTransport that fits into my use case.  Its the method that Facebook used a little while ago for Facebook Connect.  It involves an iframe on the provider page that has the same domain as the consumer page.  Trick is that you has or add parameters to the url of the iframe on the provider page.  You then have code to read this data.  This iframe then has direct access via parent.parent.jsMethodHere since they are on the same domain.  Not pretty but it works and I assume has the same bit of latency as hash transport.  Since this is for legacy support only I am not too terribly worried about that.  Only benefit to this method is that the nested iframe on the provider can call the consumer js directly and is not dependent on specifying a remote url.

I have a demo of this where the user can click on links within the iframe on the consumer and the height updates by running a few lines of code on each page therein.

On Monday, June 3, 2013 2:55:33 PM UTC-4, Patrick wrote:

Hi,

I am trying to setup an example where the 'Consumer' receives size updates from the content within the iframe.  In your resizing example you load the content within a nested iframe on the provider page.  I don't think this functionality is ideal as would require my providers to setup another page just to act as the message buffer.

What I am trying to accomplish is to provide a simple bit of javascript that will allow the provider to send the page height to the consumer (my page).  With regular postMessage this is completely possible but with the current configuration of easyXDM I am not sure if this is.  The problem lies in the way that easyXDM constructs the iframe, relying on the remote parameter, and appends the 'query' object on the URL of the iframe.  The first page loads fine and sends the page height to the consumer and the iframe is resized.  However if the user clicks on a link inside the consumer iframe, even if a socket is properly constructed in provider page #2, the message is failing to be run on the consumer.  This is because query.xdm_p is undefined and enters the wrong block of code in 'prepareTransportStack' method.

So I am curious if I am missing something... perhaps there is a way with easyXDM.  I would mainly like to use easyXDM because of the browser fallback.  

Are there reasons why easyXDM requires the 'remote' parameter instead of just setting up a listener and allowing the user to setup a whitelist check of whom to accept messages from?  Perhaps the fallback methods require this?

Thanks in advance for any insight into this issue.

Thanks,

Patrick

[Øyvind Sean Kinsey]

You'll find numerous posts about this on this mailing list - the reason for this requirement is the one time password used to secure some of the fallback transports, without this mitm attacks would be theoretically possible.

--
You received this message because you are subscribed to the Google Groups "easyxdm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to easyxdm+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.