In most cases The Same Origin Policy is desirable. It helps to prevent malicious code that could potentially reveal sensitive information from being run on arbitrary website. However, the same origin policy also makes it difficult to share resources within a common root domain, or run external widgets on your site (like displaying The Project Badge within your site). There are a couple ways to circumvent The Same Origin Policy, but I focus on JSONP and the document.domain property in this post.

Ways to circumvent the Same Origin Policy

1. JSONP
2. Modifying the document.domain property
3. Creating a server side web proxy

JSONP (JSON with padding)

How it works: JSONP dynamically creates a script element in the head of your HTML document which then requests data from outside your domain. JSONP exploits a loophole in the Same Origin Policy that allows JavaScript from an external sites to be run within your site (much like how web analytic tracking works). The JSON response, when returned, is executed within your browser at which time the JavaScript can manipulate your HTML page / DOM.

An Example Using JSONP with jQuery:

Note the callback=? at the end of the URI, in jQuery this indicates a JSONP call.

Pros

• Lets us make external calls to any endpoint that supports JSONP
• Lets us make external calls from HTTP to HTTPS
• Supported by all major browsers

Cons

• A bit more complex upfront, but most server side technologies support JSONP, browsers are natively supporting JSON, and JavaScript libraries like jQuery continue to abstract away most of the complexity.

The document.domain property

How it works: the document.domain property contains the domain of the server from which the page was loaded. For example, the domain for http://adam.kahtava.com/ would be adam.kahtava.com whereas the domain for http://kahtava.com would be kahtava.com. The Same Origin Policy restricts resource access from kahtava.com to adam.kahtava.com unless we set the document.domain property to the root domain (in this case I'd want it set to kahtava.com to share resources with http://adam.kahtava.com).

An Example using the document.domain property:

Pros

• An easy way to access resources within our root domains
• Supported by all major browsers

Cons

• Prevents us from making external calls outside a root domain
• Prevents us from switching between HTTP and HTTPS
• Kind of a hack - technically, the document.domain property is supposed to be a read only property, but most browsers also provide set access

JSONP vs document.domain isn't a cut and dry comparison. JSONP lets anyone consume and share data, whereas overriding the document.domain lets you share resources within a common root domain. In simple cases where your only concern is sharing data within a single domain (exclusively on HTTP or exclusively on HTTPS), then overriding the domain works well, but in cases where you want to share or consume external data that may be passed over HTTP or HTTPS you'd probably want to stick with JSONP.

The Project Badge makes use of JSONP so it can work on your website. Most of my publicly available web services also make use of JSONP through a WCF JSONPBehavior.

The Project Badge displays your GitHub and Google Code projects in a badge that can be displayed on your site. This widget was built on the data being returned from my Open Source Service.

View this post outside your RSS reader to see it in action or view it here.

The source for the Project Badge can be found here and the source for the accompanying service can be found here. A list of all my publicly available web services can be found here.

Using The Project Badge On Your Website or Blog

1. Add The Asset References

Add the following asset references, and a reference to jQuery (if you don't have one already).

2. Configure Your Accounts

Set your project accounts (it's OK if you only use one host) then optionally set the appropriate filters - in my case my Google Code projects were prefixed with adamdotcom and I had duplicate projects on both GitHub and Google Code. By specifying remove:adamdotcom,remove:duplicate-items in my filters I filter out the duplicates and removed adamdotcom from the project name.

3. Add The Widget Hook
Add an element to your site or blog with the id of project-badge.

That's it!
If you have any issues, use the the working example as a reference, or send me a message.

If you're reading this from an RSS feed, then the changes looks like this:

These new sections make use of the services I created earlier - my resume content is pulled directly from LinkedIn via my Resume service, the Reading Lists and Reviews are being pulled from Amazon via my Amazon service, and I'm still working on a personalized greeting module which will make use of my Whois service.

Now, when I update my resume on LinkedIn, add a new item to my Amazon wishlist, or write a new Review on Amazon the content is updated within this site and indexed by the Google.

It took longer than expected to get these new pages up and running - mostly due to a couple false starts. You see, I'm running this site on Windows shared hosting which unfortunately doesn't give me many options - sure, sure, I could purchase another hosting account, but developers are like freak'n MAcGyver we like working within ridiculous constraints. It's all about the challenge! Anyways, I first tried using Ruby on Rails on shared hosting (fail), then tried using PHP on Trax (fail), and finally reverted to ASP.NET MVC. While ASP.NET MVC is heads and tails more fun than Web Forms / Classic ASP.NET, the impedance mismatch between strongly typed objects and web languages (JavaScript, CSS, XHTML) is still annoying. Thankfully the MVC Contrib project solves some of these pains, however it can't solve them all.

My next steps with this site are to: finish the greeting module, update the layout (drop the WordPress theme), and finish a Github / Google Code repo widget (kind of like this one) for the sidebar.

Contribute, view, or download the openly available source code here.

I've joined the millions of a happy WordPress users. This site was running dasBlog - now dasBlog was pretty swell 4 years ago, but so was PHP-nuke, DotNetNuke, table-based-design, ASP.NET Themes & Skins, and ASP.NET AJAX. :) Web technology changes at an accelerated pace, and some software / technologies / frameworks need to run their inevitable natural evolutionary course (extinction). dasBlog did its job, but it's time to move on - not to mention I'll sleep easier knowing that Rhett won't be taunting me about how my blog reminds him of SharePoint. Adios dasBlog! :)

The new digs:

• WordPress running on IIS 7 hosted by GoDaddy's shared hosting plan ($203 for 4 years!!)
• Redirections by ManagedFusion Url Rewriter
• WordPress plug-ins installed:
  • FeedBurner FeedSmith - uses feedburner feeds in place of the WP vanilla feeds
  • Google Analytics for WP
  • Google XML Sitemaps
  • WP More Feeds - generates feeds for categories like musings (this feature was native to dasBlog, but not to WP)

Be sure to update this blog's RSS feed to: http://adam.kahtava.com/journal/feed/. Old feeds will continue to work, but you may experience some oddities.