When it comes to develop small microsites or web forms using cloud or landing pages, we like to take the approach of building a set of backend pages that would accept a set of parameters and return JSON, and another set of landing pages that will consume the backend using AJAX.
This methodology allows our team to run the front end and the back end development almost in parallel and make good use of front end frameworks like Handlebars, React or AngularJS among others.
But if you’ve ever tried this approach, I’m sure you ran into the same problem that we did: CORS.
CORS means Cross-origin resource sharing and is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the resource originated. For example a web page may embed images from imgur or the jquery libraries from Google. However, most servers won’t allow certain requests (usually HTTP POST requests) unless they have been originated from the same domain.
To help demonstrate the problem and the solution I have built a small landing page the returns json here: http://pub.s7.exacttarget.com/w2pm5ioz5je
And an html file that would do a POST to our page and display the message returned:
[gist id=”901e0b90e5b62e3ea572c320bcdb498a” ]
Now, if you run the HTML file locally you’ll find the following error if you look at the console output on your favorite web browser (I use Chrome):
XMLHttpRequest cannot load http://pub.s7.exacttarget.com/w2pm5ioz5je. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access
As you can see, Marketing Cloud’s Server is correctly denying our request since it doesn’t come from the same origin. Now imagine you are developing a pretty big solution and every time you had to test something you had to go to Marketing Cloud, make the change, publish the landing page and test. This could be a pretty time-consuming process, right?
In order to bypass this CORS restriction we will use Fiddler to write a custom rule before we get a response from the Server. If you haven’t used it yet, Fiddler is a very handy and nifty HTTP debugging tool and Proxy that you can download here.
Once you have downloaded and installed Fiddler, you want to go to the customize rules option:
Make sure to answer yes in the modal that is displayed when you choose this option and install the FiddlerScript editor. Otherwise it will be very difficult to find the right place to make changes (You might need to restart Fiddler to see the editor).
Once you are on the editor, you want to locate the OnBeforeResponse function. This function is returned before the server responds, as long as Fiddler is running. This is were you would make the following changes so your function looks like this:
[gist id=”fec1bfc1c3f21b607c00477f05e45202″ ]
Lastly, restart Fiddler and run the page locally again. You should now see the modal with the message that comes from our Cloud page. If you want, You can make the rule a little bit more restrictive by adding the stack so s7.exacttarget.com instead of just exacttarget.com.
You can now run your landing pages projects locally and only push them to Cloud Pages only when you are ready to do some real testing. Hope you have enjoyed the post and that you make good use of this solution!