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).
The Same-origin policy, also known as same-domain limitation.
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.
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.
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 funny graphical summary of the situation, wherein our Server-Side Proxy fits nicely at “fuck it all”:
The diagram also mentions EasyXDM and swapping data via iFrame URL (href) as viable alternatives, and they may still be for some people, but in my opinion can’t beat a solid Server-Side Proxy.
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.
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!
- What is a Reverse Proxy and How Can it Help My SEO? (seomoz.org)
- Using JSON for Private Data (mozilla.com)
- Using SignalR To Push StreamInsight Events to Client Browsers (seroter.wordpress.com)
BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.