d-Maggot's Blog //

You probably arrived at this post because you were getting a return status of 0 when doing AJAX calls. That’s either because you are using the file scheme (you’d notice because your URL starts with file://) or because you are trying a cross domain call without noticing you need a whole lot of work to get that working right.

Although cross domain scripting is still considered a very risky thing to do, thus usually blocked by default in most modern browsers, there are plenty ways to work around these blocks. I’ll be posting about headers you can use to set cross scripting permissions, yet some other common methods are the crossdomain.xml file (which I don’t like much as it came up from cross domain scripting in Flash) and JavaScript based sockets like easyXDM.

First thing to know is that the reason you cannot access other domains from your AJAX call is because browsers enforce what is called the Same-Origin Policy for JavaScript. To work around that, the Cross-Origin Resource Sharing specification was created to define headers that can configure Cross-Domain permissions between browsers and servers.

Throughout the examples, we will assume you want to fetch a resource located at Domain B from a script located at Domain A. In order to get the most basic cross domain scripting working (that is, fetching a resource from another domain) you need to return a header from the resource at Domain B accepting Domain A as an allowed origin:

once the browser receives that header, it will process the reply from the server and hand it to your script with status code 200, if successful. If you just wish to open that resource up for everyone to be able to fetch it from any domain, you can use a wildcard as the allowed origin:

Next complication level is trying to send cookies to that domain, e.g., for authentication. Your browser will not send those cookies by default unless you set your request to be a request with credentials:

And even after you are sending credentials in your request, the server at Domain B must also allow credentials

but a catch there is that, when allowing credentials, the origin must be specified explicitly (i.e., no wildcards allowed) or else no credentials are considered in the request, so you actually need to set up your response with these two headers:

so in case you want to open a resource for anybody to access it through scripts at their sites and also use credentials, you need to set the Access-Control-Allow-Origin header dynamically (see next section).

Access Control Through Dynamical Headers

One additional remark regarding Cross Domain Scripting with credentials is that  you may need to set headers dynamically per request. If the content is served from a dynamically generated resource (that’s a fancy name for a PHP script, for example) then all you need to do is use the request information to set the headers in the response. E.g., in plain PHP you would use the $_REQUEST variable and the header() function, or you could use the request and response objects of your preferred framework.

Another possible scenario is serving static content that is meant to be fetched by scripts in other domains, e.g., an image logo. Since you don’t want to allow cross site scripting for all pages served, you need to use tricks from the web server itself to set the response headers. If it’s an Apache server, for instance, you can use a combination of the mod_setenvif and mod_headers modules to generate headers depending on the requesting domain, for example:

While there’s a lot more to read, these examples should get you going with your cross domain scripting… or you may already have thought of an alternate way to avoid this hassle!