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

[findchris]

Hi all.

Two questions covered on github (please have a look: https://github.com/oyvindkinsey/easyXDM/issues/225), 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.

Cheers. 

-Chris

[findchris]

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 protocol)?

Thanks again for your time.

[findchris]

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 https://main.domain/

 - I create a channel at https://my.different.domain/remote.html (NOTE: cannot used http: here as IE block insecure content)

 - I pop open a (blank) window at https://my.different.domain/blank.html

 - I use the created channel (remote.html) to open http://my.different.domain/interesting/content.html (NOTE: this page cannot be made secure for various reasons)

So, unless I'm mistaken, I'll have to somehow create another easyXDM channel to communicate between the secure content opened in the popup and the the unsecured page that the user actually sees.  Does this sound right?  

As an aside, can you shed light as to why the opening of "blank.html" is required in the bridge example (as opposed to simply opening the page to be viewed)?

Thanks for your time.

-Chris

[Øyvind Sean Kinsey]

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 that I further improved and codified in https://github.com/oyvindkinsey/JsApiToolkit).

And as like the rest of the examples, it is just that - an example of how one can leverage easyXDM, where easyXDM is a black box providing a service (communication).

To me it seems like the issues you are seeing is elsewhere? 

- Sean 

Øyvind Sean Kinsey
San Francisco, CA

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

[Øyvind Sean Kinsey]

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.

That browsers will sometimes block HTTPS>HTTP is not one that easyXDM is designed to solve, and so you shouldn't be overriding easyXDMs behavior to try to do so either - you will most likely make it misbehave in some other way.

Instead, break apart your problems and solve them in isolation - cross-origin should already be fixed by including easyXDM, now there's just one to go :)

Øyvind Sean Kinsey
San Francisco, CA

--

[findchris]

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 that if the opener is https, then the channel (remote.html) must also be https so that IE doesn't generate "insecure content" warnings.  However, the issue arises when I want the popup to contain an insecure (http) page, since the remote -> popup communication channel has different endpoint protocols, thereby being blocked by cross-origin.  

Does the above make sense to you (and am I doing it right)?

Thanks again!

[Øyvind Sean Kinsey]

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

[findchris]

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 remote (https) to allow for communication

- The bridge in the popup creates a new easyXDM.Rpc channel, setting the 'remote' to the popup content page (content) and the 'container' to a <div> occupying 100% of the popup.

So close!  It works in Chrome/FF just fine, but:  Because the popup content page is http, IE again blocked "insecure content."  It seems to me that my changes outlined above should work, as the bridge->content channel seems to be exactly the use case that easyXDM is designed to handle.  Am I missing anything?

Again, I am very appreciative of your continued guidance.

-Chris

[findchris]

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.

[Øyvind Sean Kinsey]

Did you just answer your own question?

Øyvind Sean Kinsey
San Francisco, CA

[Chris Johnson]

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.

--
You received this message because you are subscribed to a topic in the Google Groups "easyxdm" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/easyxdm/OsksxnKMd_k/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to easyxdm+u...@googlegroups.com.

[Øyvind Sean Kinsey]

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

[Chris Johnson]

Clear as can be.  Thanks for your time.