Sometimes it's necessary to perform a cross-domain Ajax request, despite that the standard doesn't allow it. There are several ways of working around this restriction. In this post, I talk about the options, along with which you should be using (the answer shouldn't surprise you).
XMLHttpRequests have a built-in security measure denying requests made across domains. For example, a page served from www.example.com cannot make a request of a page found at www.example.org. This is nice, simple security, but is sometimes a hurdle to be overcome, such as if you wanted to dynamically make use of Google, Amazon, or Yahoo services on your site.
Instead of writing one of those articles that discusses all the ways you could do something and then concludes with how you really should do it, I'm doing the discussion in reverse.
The simplest and most obvious way to circumvent the cross-domain request restriction is to use what's called a cross-domain, or application, proxy. This is just a server-side script on your domain that performs the request from the other domain and then returns the result.
For example, your page on www.example.com might call a PHP script also on www.example.com. That PHP script makes the request from www.example.org (because there is no inherent restriction in doing so), reads in the response, and returns it to the original page. Besides being effective, this method also allows you to use PHP (or whatever server-side technology) to validate the returned data, store it in a database, log the transaction, whatever.
The code involved is really rather simple. Despite that, I can't include any here because there are so many different services out there, but the premise is just:
- An Ajax request is made of your server-side script, passing any necessary parameters along in the URL.
- The server-side script makes the request of the destination server. For security purposes, the destination should be a hard-coded URL, so that your server-side script doesn't turn into an open proxy for the entire Internet.
- The server-side script reads in the response, validates it, and so on.
- The server-side script echos out the response as valid XML, JSON, or plain text.
The Flash Bridge
There are even other options beyond those two (which are the primary alternatives to a cross-domain proxy). A search online will return a discussion of Apache modifications that can be used to work around the cross-domain requests using mod_proxy and/or mod_rewrite. But, of course, you'd need the ability to modify how your Web server runs (not something everyone has) and, do you really want to alter Apache's behavior just so you don't have to use a server-side application proxy?
Another option is to use iFrames. Although there are restrictions in communications between iFrames (or an iFrame and the main page), through URL manipulations some communication can be achieved. Still, there's limited usefulness here as a way of transmitting data and, again, there are security concerns.
It's great that there are multiple ways to do things and that smart people are striving for better options. But a new mousetrap isn't always a better one and, in some cases, may actually be worse. I'm sure plenty of people out there have a different opinion on this issue (and please offer them up in comments), but as far as I'm concerned, learn how to use a server-side proxy and forget about these others. Your dynamic Web site will work and you'll sleep better knowing you haven't circumvented one security policy by introducing new holes.