The two main options are the CORS (cross-origin resource sharing) and the JSONP (JSON with padding). Both require some server support (in the form of request headers or supported response formats), but CORS does not need anything special on the client side (except a browser to support it - which is a fact in all modern browsers).
Cross-Origin Resource Sharing
As explained by @Tiago Crizanto, CORS consists of the send server header Access-Control-Allow-Origin
next to the responses to the requests. There are some boring details (preflight, etc) but this in general is the very browser that takes care. All your Javascript code has to do is a normal Ajax request, as explained in your other question.
(Note: second this tutorial [in English], some versions of IE may need to be used XDomainRequest
instead of the traditional XMLHttpRequest
; I don’t have enough experience to give more details, so I suggest observing it if you need to support old browsers)
Examples:
Enabling CORS on the server:
Access-Control-Allow-Origin: *
Enabling CORS on the server for specific domains only (i.e. only the domain example.com
and example.net
can send Ajax requests to it):
Access-Control-Allow-Origin: http://example.com http://example.net
Enabling the sending of cookies. By default, when making an Ajax request to another domain, cookies (for example, authentication) are not included. Putting this header will make this done (caring for: may have implications on the security of your website).
Access-Control-Allow-Credentials: true
and in Javascript:
var req = createXMLHTTPObject();
req.withCredentials = true;
...
Exposing additional headers to Javascript code (by default, only headers Cache-Control
, Content-Language
, Content-Type
, Expires
, Last-Modified
and Pragma
are visible to the client code):
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
The advantage lies in the greater security: the data from the remote server is sent as the same data, noncode, so that you can give them the most appropriate treatment. The downside is that older browsers may not support it (according to the caniuse with., apart from the entire Opera Mini browser in its current version accepts it; IE8 and IE9 give partial support, and I believe that IE7 backwards does not support).
JSON with Padding
This technique in my opinion is more a "gambiarra" than a solution itself - but it is popular enough to be supported in major web frameworks (such as jQuery), and before CORS was one of the only ways to do this without resorting to external plugins or browser-specific features. It’s simple to implement, and works in any browser [that has Javascript], although it’s not exactly a "secure" solution (i.e. it should only be used if the site where the request is made is reliable).
JSONP takes advantage of the fact that some tags are exempt of same origin policy (Same-Origin Policy) - among them the script
. Since JSON is a popular data transfer format, and it is a subset of Javascript object literals, one could transmit data of this type:
{"Name": "Foo", "Id" : 1234, "Rank": 7}
using this format:
minhaFuncao({"Name": "Foo", "Id" : 1234, "Rank": 7});
To do this, just create a tag script
specifying which function you want to be called (the equivalent of callback ajax) and put the request in the attribute src
. Example (in practice, use the format supported by your server):
var script = document.createElement('script');
script.src = 'http://example.com/jsonp?callback=minhaFuncao'; // + outros parâmetros
document.getElementsByTagName('head')[0].appendChild(script);
And on the server, just serialize your answer as JSON and then "wrap it" in the callback specified. Example (Django):
objeto = {"Name": "Foo", "Id" : 1234, "Rank": 7}
codificado_json = json.dumps(objeto)
callback = request.GET["callback"] # ex.: "minhaFuncao"
resposta = callback + "(" + codificado_json + ");" # "minhaFuncao({...})
return HttpResponse(resposta, mimetype="text/javascript")
The advantage is the greater compatibility with all types of browser (it would not even need to support Ajax). The downside is in the requirement to reliability: the value returned by the server is a common Javascript code, and it runs in the same context on the home page. This means that if the server sends malicious code instead of the expected JSONP, this code can simply do whatever you want on your page (but limited to what is accessible via Javascript, which is practically all, but excludes things like cookies HTTP-ONLY
). That is, your website will be exposed to an XSS vulnerability (Cross-site scripting) - what may or may not be "manageable", but in general is a situation to be avoided whenever possible.
Interesting article. It can clarify doubts on this same theme. http://blog.dtisistemas.com.br/sharing/
– Vinícius Matos Paiva