ExtJS, Direct and cross-domain access


This post is my write up of the options to access data in a cross-domain scenario which maybe just to support the ability to develop on a machine in one domain and access data in another domain. The focus here is specifically on ExtJS (or Sencha Touch) but the comments apply more widely. The post exists because although there’s plenty of information about this topic, I found the information available confusing and I found it difficult to separate the wheat form the chaff and relate it to ExtJS. Hopefully if will seem cogent next time I need the information.

ExtJS supports two ways to access and update data in, for example but not only, grids: Ajax using json and xml proxies and the ‘direct’ proxy. When the data being accessed and updated is at the same url as the web page, called the ‘Origin’ there’s usually no problem. But browser implementations of the technology which underpins ajax normally restricts access in cross-domain scenarios. That is, requests will not complete where a web application will access or update data on another site.

ExtJS provides several proxies which are able to transport data and the most common is ‘json’. This works well when the objective is to move data to/from the origin site. However it cannot handle cross-domain calls unless you have access to the origin server and can affect the web server to correctly use the Access-Control-Allow-Origin header (more later). This is exactly like ajax because the ‘json’ proxy is just a layer on top of ajax and benefits from it’s strengths and is limited by its restrictions.

In case when access to the web server is not permitted, ExtJS provides the ‘jsonp’ proxy. This assumes the remotes data source, which is not the origin server, is able to (that is, your server side code does or you can make it) package up the response as a javascript function which can be called by the proxy when the ajax call returns. This works but it does assume functionality on the data server.

Direct

The ‘json’ and ‘jsonp’ proxies work well if the purpose is only to access and update records. What if you want to perform another action on the server, launch an activity perhaps or execute a server-side function to return a specific piece of information?

Direct is an ExtJS mechanism to execute remote procedure calls. The calls may be to retrieve and update table oriented data like json proxies but it also provides a mechanism to execute server side actions which may or may not return a value. So the direct mechanism has advantages. But, direct calls are POST calls and, like json proxies, the direct proxies is based on the browser ajax implementation technologies and suffers its restrictions. By default, a browser will only allow POST requests to be made to the origin server.

CORS

So what’s to be done when its desirable to call methods on some server other than the origin server? The answer is Cross origin Resource Sharing (CORS). This is mechanism is supported by most browsers.

Using CORS involves setting agreed headers at the web server or by a web application.

When making a request to a non-origin server, the browser will first issue a request using the ‘OPTIONS’ HTTP verb. The request will include a header that defines the type of request the browser is trying to issue and the credentials of the requestor. For example, one of the headers is ‘Origin’ which the name of the client making the request, usually in the form of a url. The web server, perhaps via .htaccess file or an application hosted by the web server, is then able to respond and include special headers which inform the browser whether or not the requestor is to be permitted or not.

Access-Control-Allow-Origin header

This is the most important CORS header. If the header is included in the response to the OPTIONS request then the browser will proceed with the attempt to process the POST request otherwise it will not. The Access-Control-Allow-Origin header must also be returned in the POST response or the browser will not complete the POST request.

The simplest way use the Access-Control-Allow-Origin header is to have all requests return:

1
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: *

The means any client is able to issue POST requests. This may be acceptable if the web server is intended to be open or if the web server is within an intranet but it probably not appropriate on most web sites. So a web server or application is able to review the Origin and other headers to assess whether the request is valid. Here’s some PHP code to look for the Origin header and return the Access-Control-Allow-Origin header if the Origin is valid.

$validOrigins = array("domain1.com", "mypc", "anotherdomain.org");
if (in_array(strtolower( parse_url($_SERVER['HTTP_ORIGIN'],  PHP_URL_HOST)), $validOrigins ))
	header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']);

Such code would be added to any PHP script that must respond to the Origin header to permit selected caller to operate cross-domain.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts

Reader Comments

Sorry, comments are closed.