Scary headline, but it’s true and I wanted to share the story. Don’t worry, it has a happy ending!
It started when Brooke shared an email from Shield Banking that said one of their clients was seeing something odd in SMG. Thankfully, they passed along a screenshot so there was little question about what was happening. As you can see below, the dashboard widgets were being blocked.
These widgets pull live data from our Google spreadsheets. When we log updates in our SMG Change Log, the widgets in the SMG dashboard automatically update. The screenshot below shows you what the dashboard should look like.
Identifying Root Cause
There are a couple of clues in the original screenshot. First, it says “blocked by your network administrator.” It tells us the blocking is a direct result of something done at the client – in this case, one of SMG’s banking clients. Second, it says “blocked due to content filtering.”
So I did some Googling on content filtering, read a couple of reference sites, and validated my research with some internal testing. A content filter in and of itself is not the root cause. It’s something companies do all the time to prevent employees from looking at porn sites, block access to known malware sites, and generally make things difficult for hackers. But content filters are driven by security policies and there’s one policy in particular that was blocking SMG.
The policy was created to stop Cross-Origin Resource Sharing (CORS). Basically, if you pull data from one website to populate another website, you are making it easier for hackers to do their thing. Blogs do this often by pulling the feeds of other blogs. Calendar counting widgets (eg, it’s been 1,233 days since Ohio State beat Michigan) are often embedded from one site but shown on another. Banks, as you can guess, have some of the strictest security policies, so many have implemented a CORS policy across their networks.
In the case of the SMG Dashboard, the policy sees data coming from both simplifya.com and google.com. I know it’s harmless and Shield knows it’s harmless, but the bank’s network has a strict CORS policy that says a website may only serve data to its users from a single domain. SMG is serving data from two domains, so it blocks the secondary domain (the widgets pulling data from google.com), no exceptions.
Remediation
There are lots of ways to remediate this issue. They range in effort from having the bank add SMG to a whitelist that allows data from a secondary domain to display, to rebuilding SMG as an in-house app (right now, it’s a WordPress app hosted by a third-party hosting company). But the circumstances called for a solution somewhere in the middle. Granted, it’s one of Shield’s clients and we want to protect that new and significant revenue source. On the other hand, the dashboard widgets communicate useful but not critical information and none of our other SMG clients are reporting the same experience.
My priority was to protect the backend process we’ve built in Google Sheets. It’s extremely efficient for the team, leverages some of the same expertise we’ve built with regulatory content production, and gives us powerful metrics for decision-making. The trick then, was to make the SMG dashboard data appear to come from a single source while continuing to rely on Google.
One way to handle this is through an Application Programming Interface (API). Instead of embedding a Google Sheet in the SMG Dashboard, we call the Google Sheets API and request that the data be delivered to our server. Then we display that same data from simplifya.com, thus avoiding the CORS policy violation. I know that probably sounds like I just said the same thing twice. The difference is that an embedded sheet displays data from google.com (violates CORS policy) while an API lets us display data from simplifya.com (doesn’t violate CORS policy).
The End User Experience
If you’re familiar with WordPress, you’re familiar with plugins. These are mini-apps within WordPress that can automate some of the more tedious tasks such as writing a bunch of API scripts to pull data from Google Sheets and writing a bunch of javascript to convert the data into nice-looking charts and graphs. To make a long story less long, I used a couple of plugins to redesign the SMG Dashboard while abiding by strict CORS policies. The new dashboard looks like this:
Conclusion
We received confirmation from our contacts at Shield that the issue has been resolved for their client. They thanked us for the ultra-fast turnaround and, maybe more importantly, they appreciate we chose not to take the easy way out. Hopefully, that means the Shield partnership will continue to grow for the foreseeable future!
Kudos to Brooke and John for handling some of the client interaction, and to Caroline for helping with the testing.