Blog

Cross Domain Data Loading with Webix

October 18, 2013

What the purpose is

Modern web apps can be rather complicated. It’s not uncommon that a single page can consume data from multiple sources, part of which can be provided by third party API or by a related application that resides on some other site. And that is where a problem occurs. A page hosted on one domain can’t access data from a different domain.

For example, if you have a page hosted on http://app.mydomain.com, which tries to load data from the http://data.mydomain.com, the data loading will fail. Any browser blocks such kind of data loading operation for safety reasons. Moreover, a request to a different port, such as http://app.mydomain.com:5000 for example, will be blocked as well. URLs pointing to the same domain but to different ports are treated as URLs pointing to different domains.

There’s a solution for every problem. If we speak about Webix, it can use two techniques to avoid the pitfalls of data loading: cross-origin resource sharing and JSONP.

Cross-origin resource sharing

The first technique that we can use for the cross-domain request is CORS – Cross-origin resource sharing. This is a standard for cross-domain data interactions. By configuring the data server correctly, you can give access to the data to any scripts from other web domains.

When initiating a cross-origin request, a modern browser sends the request with an Origin HTTP header. This is a default browser behavior – so far we don’t need to change anything. The value of the header is the domain of the master page, from which the request has been initiated. For example, let’s suppose that a page from http://app.mydomain.com attempts to access user’s data from http://data.mydomain.com. The command sending a request will look as follows:

webix.ajax("http://data.mydomain.com/data.php", function(text, data){
table.parse(data.json());
});

A browser will automatically include the next header into the HTTP request:

Origin: http://app.mydomain.com

Now, the server must respond with a specific header as well. The response will be similar to this one:

Access-Control-Allow-Origin: http://app.mydomain.com

Such a response informs the browser that the server at data.mydomain.com allows a program from app.mydomain.com to use its data. It should be said that this response is not enabled by default. You need to configure either the server’s settings or the code of your app to output the header as a part of server response.

If you are writing a code that consumes some third party API, there’s a good chance that the API server is already configured in the necessary way to support CORS protocol.

You can get more details about CORS configuration in this detailed guide.

Summary

The advantages of CORS technique are:

  • standard based
  • no changes needed in the client side code
  • doesn’t require any extra code or any changes in the server side logic
  • can be used with any kind of data (structured or not)
  • can be used with all types of requests – GET, POST, PUT, DELETE, etc

The CORS drawbacks are:

  • requires server reconfiguration
  • doesn’t work in IE8, IE9

JSONP

The second Webix’s communication technique is JSONP, which means “JSON with padding”. As well as CORS, it can be used to request data from a server that resides in a different domain. However, on the client side the JSONP request has some specific features. The command sending a request must be issued as follows:

webix.jsonp("http://data.mydomain.com/data.php", {}, function(data){
table.parse(data);
});

Thus the syntax of JSONP command is quite similar to that of webix.ajax. The above command will issue a request to the target script and will provide the loaded data in callback. One more important feature that differs JSONP from webix.ajax is that JSONP always provides structured data, not a raw response text.

To support the above kind of request, the server side code at data.mydomain.com must be configured in a specific way as well. Look at the following structure:

$data = get_data_in_some_way();
$json_data = json_encode($data);

$jsonpname = $_GET["jsonp"];

header('content-type: application/json; charset=utf-8');
echo $jsonpname."(".$json_data.")";

As you can see, the response data is wrapped, encoded as JSON and is sent back combined with “jsonp” parameter. Webix hides all technical details of JSONP handling , but still you need to have a custom code on both client and server sides.

To get more details about how JSON works you can check the article in Wikipedia.

Summary

JSONP advantages are:

  • works in all browsers
  • doesn’t require server reconfiguration

The shortcomings of JSONP are:

  • requires a specific client side code
  • works only with structured data
  • is prone to XSS attacks
  • works only with GET requests

What technique to choose

The answer depends on the specificity of your project. The major difference between CORS and JSONP techniques is the support of old IE versions. If this support is the mandatory requirement, you need to go with JSONP. Otherwise, CORS is a better solution, as it’s more safe, standard based and requires less coding.

Share on Twitter Share on Facebook Share on Stumbleupon Share on LinkedIn Bookmark on del.icio.us Vote on Reddit
  • monsur

    Not sure I agree that JSONP “doesn’t require server reconfiguration”. As you point out above, the server needs to be reconfigured to wrap the JSON response in a callback.

    • Maksim Kozhukh

      Yep, for jsonp you need to change the code of data generation. But in case of CORS it may be necessary to reconfigure a server itself (apache, nginx, etc.) to send or allow a necessary HTTP headers.