BCmoney MobileTV

Image via Wikipedia

The Server Side Proxy… oh how I despise thee.

It’s a technique which we wouldn’t have to utilize at all, were it not for Browser security restrictions (which are admittedly in place for a good reason, to save us from ourselves).

Problem

The Same-origin policy, also known as same-domain limitation.

Reaction

After IE4 and a number of other browsers had vulnerabilities revealed where Cross-Site Scripting (XSS) attacks were exploited to gain access to user data, jeopardize accessibility of, or otherwise vandalize popular Web Services and Web Applications, the Browser vendors got together and decided to lock down their browsers into a “sandbox”.

What is a sandbox you ask? In non-developer speak its just like you can find in public parks, a set of boundaries around a soft and malleable plot of land where you can play safely and fall down as much as you want without hurting yourself (or others). Even if you did decide to go on an all-out rampage, you could only at most hurt other people inside the sandbox. In geek speak, its a security mechanism for separating running programs whereby code is isolated to its own space in memory and/or its own path on the network. This effectively means your client-side code can’t make a request to any URL above its own path, let alone to an external Web Service or application.

Solution

Create a server-side proxy to by-pass the Browser security restrictions! Well, this is one approach at least. Others include web server hacks, a Flash object with Cross-Domain policy and use of JSONp, but each of those may severely limit what types of data and services you can work with.

For instance, JSONp requires a Web Service which supports insertion of JavaScript callbacks; furthermore, it requires you to trust the service provider completely as they have access to inject new scripts or activate your own JavaScript code at their wish, should they choose to abuse your trust (or naivety). So that rules out JSONp for all but the most trustworthy domains.

Likewise, Flash requires the activation of a cross-domain policy on the server you are trying to access remotely which expressly states that site’s trust of your domain. This can be done by placing your domain in a sort of white-list via a crossdomain.xml file at the root of their domain. This enables your domain to access data through Flash, or, the service provider may naively itself offers up access to their domain to everyone by default (i.e. YouTube, Yahoo!, Amazon, this site, etc).

As far as the server hacks, they require major extensions to be installed and rewriting access rules on your own server configurations (which you may or may not have full control of as a developer in a big enterprise, or, a user of payed hosting solutions). Last but not least are more modern approaches such as Cross-Origin Resource Sharing (CORS), which, while well-meaning in nature, still leave a lot to be desired, because the browsers put the sandboxes in place for a reason.

Here’s a nice graphical summary of it all:

Image courtesy of iluvrhinestones on flickr (CC:sa-by)

So that sets us up for the best go-to solution at this point.

The Server-Side Proxy

The Server-Side Proxy could be anything from a basic snippet of code required to receive a URL and make an HTTP request to it, to a complex authentication-based, whitelist-driven, data validating, usage-metered piece of complete software. You can write a proxy in just about any modern programming language that supports network access, but I’ve developed and collected several examples in some of the most popular programming languages, each with their own dependencies and advantages/shortcomings. In particular, compare the approaches available in HTML5 to other common web-based techniques of using Flash or JSONp.

See the full text links below:
PHP | Python | Perl | Ruby | Java (Servlet) | JSP | ASP.net | C# | C | C++ | Objective-C | LISP | Flash | AJAX (JSONp) | HTML5 | CSS

OR

UPDATE (2010-12-09):
Several of these proxies may be outdated against latest versions of each programming language, dependency libraries used, or, there just might be a better/more secure way of doing it, please help me to update the source code on snipplr!

Related Articles

• What is a Reverse Proxy and How Can it Help My SEO? (seomoz.org)
• EasyXDM – crossdomain javascript done right (zemanta.com)
• Why use a Javascript UI for Solr? (css.dzone.com)
• Using JSON for Private Data (mozilla.com)
• Using SignalR To Push StreamInsight Events to Client Browsers (seroter.wordpress.com)

The Server Side Proxy… oh how I despise thee. It’s a technique which we wouldn’t have to utilize at all, were it not for Browser security restrictions (which are admittedly...