To paraphrase Chris Brown, these CDNs ain’t loyal. If you used Socket.IO for your web app, you may have run into a few issues today, 5/27/16. A few issues is probably a bit of an understatement, as any secure app that used Socket.IO’s CDN to serve their client the necessary library to communicate with their server today was crippled. The culprit? Socket.IO forgot to renew its SSL certificate, which had a cascading effect since their website thus could not serve the file to any app that relied on their CDN to supply it via a secure protocol.
My app, NoSurge, which is really just a glorified WebView with a Node.JS back-end, also uses an SSL certificate. This is partially for security (although I don’t request anything more than a user’s location), but mainly because one day non-HTTPS domains will be unable to get a user’s location in popular browsers (“Chrome has public intent to deprecate powerful features like geolocation on non-secure origins, and we hope that others will follow.“) However, by serving my page with a secure protocol, I’m unable to load JavaScript files that aren’t also from a secure origin. So when Socket.IO’s certificate became invalid on May 27th, my app no longer worked.
It’s unfortunate at best, and pretty unfathomable that a major provider of a library used for developers would not be on top of their SSL certificates. It is not hard to maintain an SSL certificate these days, thanks to free, easily renewable certificates provided by Let’s Encrypt. (It’s what I use for NoSurge. A one-time setup, and the addition of auto-renew lines to your crontab is all you need to never have to worry about your SSL certificate expiring!)
I had a surge (no pun intended) in uninstalls and unhappy users for NoSurge today. While it was frustrating, I myself also learned a lesson: always have a contingency plan for when CDN-hosted files and other resources you depend on another party for break. It was a simple fix to get NoSurge back up and running (I just downloaded a copy of the socket.io.js file, hosted it locally, and changed the reference to the file in my app accordingly), but I *should have* had error handling in my app in case Socket.IO’s CDN did not load, so I could have at least served the user an error (or better yet, served the missing file from my own server). That said, it’s still extremely frustrating that a CDN for a major JavaScript library gave everyone who used it a headache today.
Oh, and here’s the kicker: This expired-SSL-certificate-causing-everything-to-break-thing apparently happened last year as well. So maybe its time to find a new CDN.