Recently we got the chance to tackle a really fun CORS problem and I want to share our experience and thought process behind finding the appropriate solution.
The Problem
Last year we built a really complex Beaver Builder solution for one of our clients where we customized the modules with options and settings specific to their brand guide. This gave them a ton of flexibility in the kinds of landing pages they could create and empowered editors on their staff to make updates without having too many options. They loved this solution so much in fact that they asked us to figure out how to enable this kind of functionality on their support site running on MindTouch.
After a quick review of MindTouch it was clear that there was no way to include a Beaver Builder style page builder into its editing capabilities. While we do have ways to load our own custom scripts and styles, we don’t have the ability to add PHP or server-side code customizations so we had to rule that out right away.
Cross-Origin Resource Sharing
Instead of building content in MindTouch, we decided to have the client create content on a dummy page through the WordPress site, thus giving them the Beaver Builder functionality. We’d then pull that content over via an iframe or something similar. As we’ve experienced before, iframes are pretty terrible to work with and the user experience was unacceptable. So this left us with the idea of using some sort of JavaScript-based solution since we can at least add our own custom script.
After a bit of thinking and tinkering we came up with a solution that looks a bit like this:
So we call the main site via AJAX (we already have jQuery loaded so it makes sense to just keep using it here) targeting a specific element and then pull the response and return that element’s HTML to the page. Awesome! Well, sort of…this is where we run into a bit of an issue with CORS (Cross-Origin Resource Sharing).
Our browser doesn’t like the fact that we are trying to use JavaScript to grab content from a different domain so it will actually just block the request. This is a good thing normally, but in our case we actually need it to work.
Possible solutions for CORS
Through our research of the problem we found that we were pretty limited in terms of solutions to this type of problem. We narrowed it down to two options to use.
Using htaccess
This method is actually really simple. You can simply go into the .htaccess file of the main site and add a rule to allow the request from the other domain. Something like this:
Beware though: this solution worked in our testing, but there are many ways a server can be configured and this might not always be the solution for you. That is exactly why we chose to discard this method and go another route.
We wanted to make a solution that was a lot more flexible and didn’t depend on the hosting site running a certain type of server setup in order for it to work. Looking for other solutions helped us to discover Cors Anywhere.
CORS Anywhere Method
After a bit of diving into CORS Anywhere it seemed like the perfect fit for us and more of the ideal solution we were hoping for. All we needed to do at this point was setup a proxy domain that we could use and then go through the CORS Anywhere installation steps. So it went something like this for us:
- Spin up a new blank Digital Ocean server
- Install node to the new server
- Install CORS Anywhere
- Add the appropriate code from the instructions
- Test test test!
- Secure our new server and only allow the proxy URL to process for specific allowed sites (similar to the htaccess restriction)
Voila! After all that we just had to go back and change our AJAX request URLs to use the new proxy URL:
Now we have a proxy domain that we can use for any type of CORS projects we need in the future and it is server agnostic since we run it from our own!
Have you used the CORS Anywhere project or something similar? Share with us in the comments!
