Shopify App Console and Firefox Quantum 302 Redirect

Source

The new update to Firefox, the Quantum (v57.0), is blazing fast, thanks to some fantastic performance improvements. As a web developer, I am thrilled to see Firefox give Chrome a run for its money once again, the healthy competition can only be good for the ecosystem. However, every upgrade comes at a cost to backward compatibility — and not always are those changes obvious. Some of our customers at Swym Corporation, who happen to be Shopify store admins (who use Firefox Quantum) started encountering some errors while accessing the app directly via their Shopify Apps console. The page just seemed to hang around, and ended at “connection timed out” after a minute or so. It took us some back-and-forth to figure out this was a Firefox Quantum specific issue, but once we had a reliable repro, we were able to narrow things down quickly. We wanted to share a summary of our learnings in the hope that it might benefit others that stumble into the same thing — please note that the post is very specific to the Shopify store admin scenario that our users encountered, and not meant to be a general Firefox Quantum debugging guide.

Expected/Correct flow

During a normal login action (as experience in previous versions of Firefox),

  1. Admin logs in to Shopify Admin and navigates to the apps page
  2. Clicks on a link in the app page
  3. The link opens in a new tab
  4. Shopify sends back a HTTP 302 redirect with location as the app install url with additional parameters like hmac, shop and timestamp parameter. This contains the protocol as well
  5. The browser reads the HTTP 302 redirect and loads the url specified in “Location” header as-is
  6. Everything works as expected

The erroneous redirect

In step 5, Firefox Quantum forces the redirect url to HTTPS in spite of the Location header value having only HTTP. At this point, the browser/page just hangs and times out as there are no listeners for the HTTPS protocol on the app server.

Digging a little deeper with the help of network traces — This is the first redirection received on the browser after clicking the link,

You can clearly see here, that the scheme is “HTTP”.

Moving ahead, the network sequence is below,

In the second request, the redirect url has now been forced to “HTTPS”. Similar result when we tried opening console and called window.location = <<the href url on the anchor element>>. Hung page, looking for HTTPS and page times out.

Removing HTTPS context

Next we wanted to find out if this was the general case even without a previously loaded https context. So we tried the below (opening up a new tab)

  1. Right clicking on the app name and choose “Copy link address”
  2. Open a new tab
  3. Paste the url and hit enter
  4. Page loads as expected, with the below network trace

Observing from the above scenarios, it looks like Firefox Quantum forces the current page’s scheme on any redirection based from that page, which includes

  1. any HTML anchor hrefs
  2. javascript based redirection (setting window.location and calling window.open)
  3. HTTP 302 response with “Location” headers.

We ran the tests for Firefox Quantum running on a Mac Sierra and Ubuntu 14 with the same results, both normal and private browsing sessions.

Running quick tests on Chrome and Safari, the redirect Location header is used as passed, so everything works as expected.

Potential Impact

This could potentially break any apps/sites that haven’t fully upgraded to HTTPS. Not just the login but also the installation scenario, which means you might be losing existing and new customers! Especially with the speed boost in Firefox Quantum, the browser user-share graph will probably see a shift.

Solution

It doesn’t look like there is any way around this other than upgrading your app servers to support HTTPS.

Long story short

It is time to start adding HTTPS to those app servers you got! AWS, Microsoft Azure, Digital Ocean and other cloud hosting providers have solutions to quickly set it up on your servers. Most browsers still support HTTP but posts like these indicate that it will get harder to be just HTTP enabled.

Disclaimer — Shopify app configuration does allow HTTP for the endpoints.

Notes

General debugging notes that we followed to get the network traces via the browser,

  1. To view the network requests you can try right click on the page, Inspect Element and go to the network tab.
  2. For links that open in new tabs, the best way to get the network stack will be to remove target=”blank” in the anchor tag and then click on it
  3. If you already have setup Fiddler (Windows) or Charles Proxy (Mac) for HTTPS proxy, then you should be set to view these requests without the browser’s inbuilt debugger.

User agents we tried it on

  1. Firefox Quantum Ubuntu — Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
  2. Firefox Quantum Mac — Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
  3. Chrome Mac — Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
  4. Safari Mac — Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.1.1 Safari/603.2.4

Thanks for reading, hope this was useful. Do let us know if you ran into the same problem and found other ways to get around it — or if you have any comments/additional information on the issue.

Recommended Posts

Leave a Comment