Thursday, November 10th, 2005

Solutions to allow XMLHttpRequest to talk to external services

Category: Articles

<p>Over on XML.com they published Fixing AJAX: XmlHttpRequest Considered Harmful.

This article discusses a few ways to get around the security constraints that we have to live with in the browsers theses days, in particular, only being able to talk to your domain via XHR.

The article walks you through three potential solutions:

  1. Application proxies. Write an application in your favorite programming language that sits on your server, responds to XMLHttpRequests from users, makes the web service call, and sends the data back to users.
  2. Apache proxy. Adjust your Apache web server configuration so that XMLHttpRequests can be invisibly re-routed from your server to the target web service domain.
  3. Script tag hack with application proxy (doesn’t use XMLHttpRequest at all). Use the HTML script tag to make a request to an application proxy (see #1 above) that returns your data wrapped in JavaScript. This approach is also known as On-Demand JavaScript.

I can’t wait for Trusted Relationships within the browser – server infrastructure.

With respect to Apache proxies, these things are priceless. I recently talked about them in relation to Migrating data centers with zero downtime.

What do you guys think about this general issue? Have you come up with any interesting solutions? Any ideas on how we can keep security, yet give us the freedom that we want?

It is interesting that Zimbra takes the “install a local proxy” approach.

Related Content:

8 Comments »

Comments feed

I’m using on-demand JavaScript successfully in a cross-domain AJAX application. I used the excellent browsershots.org to test the technique in all the common browsers and it works perfectly in all but Konqueror, and I believe the latest version of Konqueror (in beta at the time of writing) will support it.

Comment by Richie Hindle — November 10, 2005

Richie,

Very cool. Are you using On Demand in the same way as the article?

Cheers,

Dion

Comment by Dion Almaer — November 10, 2005

I think using a ‘bookmarklet’ falls into this category. The Mouseover DOM Inspector (http://slayeroffice.com/tools/modi/v2.0/modi_help.html) uses this approach, which is interesting. The main problem I suppose is when the code changes, the user must update the bookmarklet.

Comment by Jason Pollard — November 10, 2005

On-demand javascript is also the way of Jini ;-)

Lately, I’ve been considering how to combine Ajax and Jini. Tough problem since Jini assumes a JVM for the downloaded proxy. Using Jini surrogates is one possibility… I’m still thinking this one through.

Comment by Dale Asberry — November 10, 2005

GreaseMonkey can do the script, when suitable.

See my comment at http://spaces.msn.com/members/siteexperts/Blog/cns!1pNcL8JwTfkkjv4gg6LkVCpw!2332.entry

Comment by splintor — November 10, 2005

Greasemonkey definitely allows to experiment in that space, but it’s still an all-or-nothing solution to security.

There has been some discussion and even an informal RFC for a cross-domain XHR funtion:
http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html

Essentially, it proposes not to send cookies to the server and also let’s the server restrict it’s response to be used in a same-domain situation only.

Comment by Julien Couvreur — November 10, 2005

Dion: Yes, I’m using what the article calls “DOM-Based On-Demand Javascript”, creating a script element programmatically and adding it to the head.

Comment by Richie Hindle — November 11, 2005

We have always used Apache’s Mod proxy to achieve cross domain and cross port aggregation and rewriting.

Apache kicks but for any static content, thus ones web app shouldn’t even touch it. Often different parts of the web applcation itself exist on different url/context or even different ports. The proxy feature enables one to partition the web application in a very reliable and flexible manner. Normally we would be running at least 3 different parts of a web app by default :
1) Static content (always apache)
2) Dynamic page content usually servlets running under Jetty
3) AJAX controller and dynamic REST app running under jetty (canm actually change these settings)

Also Apache can cache some of the stuff which really reduces your web app load

regards
Al

Comment by Al — November 11, 2005

Leave a comment

You must be logged in to post a comment.