This Is Unsafe

Against my better judgement, I upgraded to MacOS Catalina. After surviving a panic when the upgrade was seemingly stuck “estimating time remaining” (I left it alone; the process ended up taking about 2 hours total) I fired up Chrome and tried to get to work.

The project I work on uses self-signed certificates for local dev, generated on the fly by an npm module called pem. This has always resulted in big warning page from Chrome about the certificate being invalid, but it’s always been easily bypassable by clicking the Advanced button and clicking the option to proceed anyway.

However, after the upgrade, the error page changed as shown above. Now it says the certificate is revoked (NET::ERR_CERT_REVOKED), and no longer gives me the option to proceed.

First, I was a little confused how the MacOS update caused this. I assume it’s tied to some connection between Chrome and the OS, but curiously, I did not have this same problem with Firefox. I thought it might be something that changed in Chrome itself, but I verified I do not have this issue with the same version of Chrome on Linux. I really didn’t want to spend hours going down this rathole (but, alas, so I did) and just wanted to get back to work, but sometimes that’s not how it goes in the life of a software developer.

So, my first sign of hope was this page I found. Seems there was a change where certificates with an expiration date greater than 825 days are no longer accepted. Looking at the code, I see the certificate being generated by pem is set to be valid for 3650 days. That must be it!

This did cause a change in behavior. Now instead of NET::ERR_CERT_REVOKED, I got the same page but with a different error: NET::ERR_CERT_INVALID. This is the same error I’m used to, but I still am not given the option to proceed.

I could not find anybody running into the exact same issue as me. I pondered trying to find a different NPM module (not at all confident that would help), generating a static certificate file and importing it into Chrome, starting Chrome from the command line with “–ignore-certificate-errors”, and myriad other solutions, all of which seemed less than ideal, when I stumbled across this forum thread from 2017. It wasn’t exactly the same scenario, other than the OP was also trying to bypass the NET::ERR_CERT_INVALID error.

When I saw this response, I honest to God thought it was a sarcastic joke, but out of desperation, I tried it anyway: There’s a secret passphrase built into the error page. Just make sure the page is selected (click anywhere on the background), and type thisisunsafe

I clicked back on my Chrome window, typed in the characters “thisisunsafe” (didn’t even have to hit Enter!), and lo and behold, my local dev site is back in all its glory!

Hope this helps someone else out.

Safari blocking new window opened from clicking button in web application

I work on a web application that includes a feature that integrates with another of my company’s products. You trigger the integration by clicking a button in the first web app, which launches the second web app and passes along a document. The code is a little something like this:

$(document).on('click', '.my-button', function(e) {
  $.ajax({
     method: 'POST',
     url: '/api/call/to/get/the/url/we/need/to/open',
       error: function (status, err) { },
       success: function (data) {
         window.open(data.redirectUrl);
        }
     });
});

I mostly use Chrome on either a Mac or Linux laptop and this has worked fine. But yesterday I got a report that the button was not functioning on Safari. Turns out that the window.open was being blocked by Safari’s popup blocker. Of course, the easiest thing is to just tell the user to turn off their popup blocker. But that’s obviously not ideal.

So I did some digging and found other people had run into similar issues with Safari. But the solution is relatively simple, according to this StackOverflow link. Do the window.open first, with no target, and then set that window’s location.

However, this still didn’t fix the issue for me. Digging a little deeper into the comments on the post, one additional thing I discovered is that the ajax call that’s triggering this also needs to _NOT_ be asynchronous. Well, this is not ideal, but the web app is basically blocked until this completes anyway, so this turns out to be a good enough solution for now. The API call is pretty fast, but I throw up a little temporary modal with a spinner while this is being processed so the window doesn’t just completely freeze up with no feedback.

So the fixed code looks a little like this

$(document).on('click', '.my-button', function(e) {
  $.ajax({
     method: 'POST',
     async: false,
     url: '/api/call/to/get/the/url/we/need/to/open',
       error: function (status, err) { },
       success: function (data) {
         var newWindow = window.open();
         newWindow.location = data.redirectUrl;
        }
     });
});

Hope this helps someone! And of course I welcome any feedback on better ways of handling this.