Best long term choice: JSONP vs EasyXDM

What is the best long term choice between JSONP and EasyXDM to allow a domain on http to talk to the same domain on https (cross-protocol)?

For example, I would like that http://mywebsite.com talks to https://mywebsite.com because the session cookie is only over ht开发者_JAVA百科tps. I would like to display a user name on the http website without having that data being transferred over http.

EasyXDM is scaring me with security release and JSONP is not very clear on the security precautions.

Disclaimer: I'm the main author of easyXDM.

It is actually not easy to answer this directly, as there are many things to consider.

First, lets compare easyXDM and JSONP outside the scope of the question.

JSONP allows a client side program (Javascript using the BOM/DOM) to interact with a server side program(.net, php etc using db's, session storage etc), and it is only the client that can initiate messaging (request/response, polling, or push, although for push you could easily set an IMG.src, do XHR or a FORM post as you do not require a response).
The client is limited in the amount of data it can send to the server, and this data must also be formatted to fit as a query string parameter, and the server must be set up to respond to said data. For each message a network trip is run with the cost this incurs.

easyXDM facilitates messaging between any two client side programs using a string based transport stack. There does not need to be any server side programs involved, and there is no network traffic. The two sides are both equal and can both initiate messaging, and can both keep state on the client (hence the term programs instead of plain Javascript). The messages are not limited in size, and as long as the data can be serialized to a string, the transport can handle it (easyXDM allows you to set a custom serializer, or to use JSON).

The main difference between these two are that one is between a client and a server where only the client can initiate messaging, and that the other is between two equal client programs, where either one can use XHR and other means to communicate with, or relay data to a server.

Regarding security; JSONP demands that the client trusts the server absolutely, after all, it allows it to run arbitrary code in its program. Other than this, there are few issues, but this is a grave one.
With easyXDM only information (the string) and no code is transmitted, and it is up to the receiver to inspect the information and act on it. So there is absolutely no risk of execution of arbitrary code. While the above is true, some of the components that easyXDM relied on to establish the channel were vulnerable to XSS (a specially crafted url would cause the client to execute arbitrary code), but these have been closed. At the present no such vulnerabilities are known, and all new code is vetted thoroughly.

I myself use easyXDM for a few demanding projects, and sites like LinkedIn, Twitter and Disqus as well as applications run by Nokia and others have built their applications on top of the messaging framework provided by easyXDM, so there are many people who have gone over the code and checked it, and who through using it vouch for its security.

In the end, it is really about the use case. For example, JSONP can not be used for resizing a window across domains, as that require client/client communication. But easyXDM can be used for both client/client, and client/server by having one of the parties use XHR.

In your case, neither of these are really required if you need merely to make a small piece of information available on the unsecure domain.

• Navigate through the secure domain, set a cookie on the unsecure one
• Navigate through the secure domain, have it redirect to the unsecure passing information in its request
• Navigate through the secure domain, have it store data in window.name before redirecting to the unsecure one.

If it is vital that the information cannot be spoofed, then you for all of these need to sign the data so that its authenticity can be confirmed, but if all you need is a name then this should be unnecessary.
A simple way to check the authenticity is to

• On the unsecure domain, generate a random secret and store it, and redirect to the unsecure domain passing the secret.
• On the secure domain pass back the secret together with the information (using either of the means described above)
• on the client verify that the information contains the secret.

Since only the two parties could possibly have the secret, the information is verified.

To conclude, there really is no definitive answer, it all depends the situation. So choose, but choose wisely :)