easyxdm Google Group

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (Chris Johnson) — Tue, 21 May 2013 03:01:31 UT

Clear as can be. Thanks for your time.

Re: Can you override the transport used? Must the remote protocol match the parent?

oyv...@kinsey.no (Øyvind Sean Kinsey) — Tue, 21 May 2013 01:59:07 UT

These are orthogonal problems and easyXDM can do nothing about this warning.

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (Chris Johnson) — Tue, 21 May 2013 01:52:46 UT

I don't think I did. Did I?
I thought easyXDM would provide a way for this communication to work
without the IE content warnings. I guess I am looking for confirmation
that what I want to do is not possible, with or without easyXDM.

Cheers.

Re: Can you override the transport used? Must the remote protocol match the parent?

oyv...@kinsey.no (Øyvind Sean Kinsey) — Tue, 21 May 2013 01:40:37 UT

Did you just answer your own question?

Øyvind Sean Kinsey
San Francisco, CA

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (findchris) — Tue, 21 May 2013 01:31:38 UT

A concise rewording of my previous message: Can easyXDM make it so that a
secure (https) page can communicate with a non-secure (http) embedded
iframe (same domain, different protocol)? IE report "insecure content" but
all other browsers work.

Cheers.

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (findchris) — Sat, 18 May 2013 00:15:37 UT

Thank you very much Sean for your time.

I feared that what you said is the case, so I went ahead and added another
proxy in the following way:
- The opener opens the remote on the same protocol (*https:)* to avoid
mixed content warning in IE
- The remote opens a bridge page in the popup using the same protocol as

Re: Can you override the transport used? Must the remote protocol match the parent?

oyv...@kinsey.no (Øyvind Sean Kinsey) — Fri, 17 May 2013 23:16:30 UT

In this case the remote and the popup *has* to be on the same origin, since
the remote is acting as the same-origin proxy to the popup.

Øyvind Sean Kinsey
San Francisco, CA

Re: EasyXDM with popup in ios6

aaronlloydpeter...@gmail.com (apson) — Fri, 17 May 2013 21:56:55 UT

Did this end up being a successful workaround for the safari bug? Thanks.

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (findchris) — Fri, 17 May 2013 19:10:44 UT

Hi Sean, and thank you very much for your responses.

This is definitely not an issue with easyXDM per se, just my understanding
of how to correctly use it ;-)

My implementation is quite similar to the bridge example, where a pop up
needs to communicate events back to the opener. The heart of the issue is

Re: Can you override the transport used? Must the remote protocol match the parent?

oyv...@kinsey.no (Øyvind Sean Kinsey) — Fri, 17 May 2013 06:44:14 UT

All transports are controlled by the consumer, and whichever protocol the
consumer sets, the provider will choose too.
While this can be specified in the config (mainly for testing), this is not
something you would normally want to do, as easyXDM will no longer be able
to chose the most optimal transport.

Re: Can you override the transport used? Must the remote protocol match the parent?

oyv...@kinsey.no (Øyvind Sean Kinsey) — Fri, 17 May 2013 06:33:39 UT

The whole point of easyXDM is to let pages of *different* origins to
communicate, where the difference might come from different protocols,
domains, or ports, so there is either a configuration issue, or the error
is outside of easyXDM.

Now, the bridge sample is definitely the most complex use of easyXDM (one

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (findchris) — Thu, 16 May 2013 21:45:34 UT

Ok, it looks like the FlashTransport is (unsurprisingly, I guess) subject
to the same origin policy like other transports, so protocols and domains
must match.
I'll try to shed more light on my situation (this maps pretty well to the
bridge example):
- Main page is http*s*://main.domain/
- I create a channel at http*s*://my.different.domain/ remote.html (NOTE:

Re: Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (findchris) — Thu, 16 May 2013 17:20:30 UT

It looks as you can override the protocol used by simply adding the
protocol to the options hash (e.g. "6" for FlashTransport).
Does anyone know that when using the FlashTransport:
(1) Both easyXDM endpoints need to define the protocol in the options?
(2) It bypasses the need for the URL root to be the same (e.g. same http

Can you override the transport used? Must the remote protocol match the parent?

findch...@gmail.com (findchris) — Thu, 16 May 2013 00:53:36 UT

Hi all.
Two questions covered on github (please have a
look: [link]), but summarized
here:
(1) Can you override the transport used in Rpc?
(2) Does the remote's protocol (e.g. http(s):) have to match that of the
parent window?
Please see the linked issue on github if this is unclear.

Re: No access to provider?

oyv...@kinsey.no (Øyvind Sean Kinsey) — Mon, 13 May 2013 22:44:58 UT

Sorry, wrong tree then. You need to use CORS, if supported, or maybe a
flash component, if that is supported. Or tunnel it through your own
backend.

Øyvind Sean Kinsey
San Francisco, CA