Beakyn
Published in

Beakyn

Intercept and change all outgoing requests on your app with Service Workers

Disclaimer: This did not go the way we wanted. But if you want to learn what we learned keep reading.

Do you know that awesome feeling you have when you fix something but then it becomes a terrible feeling five minutes later when you realize you didn't, actually, fix anything?

Hey everybody, Juan here.

Let me ask you something, what if you are forced to load some shitty insecure resource on your beautiful and HTTPS protected web app? Chrome will say, “nope” mixed content. Now what? Are you fuc!@#!? Do you give up your dev career, become vegan and annoying? No, you use a reverse proxy, like this one: https://cors.now.sh/, this thing is amazing, we have our own deployed and it saved our bacon many times!

I’m done here

Wait! what happens if you try to load a shitty and insecure (HTTP) script using your fancy new reverse proxy but that script makes more requests that you have no way to change?

Oh shit!

So, we have this amazing React app that does crazy stuff with maps and charts. We needed to integrate some visualizations that are rendered using a remote enterprise service, and this needed to be ready for an upcoming presentation. The service couldn’t provide an SSL certificate for their domain in time, so we decided to use our reverse proxy. The problem with that are the subsequent requests their framework does under the hood. We can’t append our proxy to those calls, can we? Well yes, you can, if you use a Service Worker interceptor.

So, here is where I’ll let Lucas explain why Service Workers didn’t help the way we wanted to. What? I’m the CTO, I’ve people that do stuff for me. Don’t judge!

From Lucas:

Don’t use non-https stuff!

Now, seriously, this is what he said:

As you know, service workers should be able to intercept all kinds of requests, including opaque ones. The main problem is that when we’re dealing with external APIs where we don’t have any control, including script tags on the DOM, and making subsequent requests created from redirects, etc. These are all opaque requests that can’t be intercepted with JavaScript.

Services workers are the only way to intercept opaque requests or you can create a chrome extension and use the WebRequest API. But the pitfall here is that we were trying to intercept non-SSL requests and turn it on https with our reverse proxy server. That didn’t work for only one reason: service workers can’t even intercept non-SSL requests. They only work with https, everything else that isn’t is ignored and doesn’t even trigger the fetch listener.

If we were trying to create any other kind of interceptor (for https URLs), this would have been a success.

Mental note: service workers + non-SSL = nothing happens!

That’s where Lucas’ explanation ends! Thanks a lot, man!

This is me, again, and well, there you have it. Maybe were wrong, maybe it needs more research and I would love if somebody left a comment in the lines of:

“Hey stupid! You could do this or that”

And if it actually worked it would be amazing.

Anyways, hope this wasn't a complete waste of your time. Part of the culture at Beakyn is to share our wins and our losses and to keep learning, always.

Have a great week.

--

--

--

Tech mad science and stuff

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Juan Pujol

Juan Pujol

Building apps with perfect balance between user experience and code architecture

More from Medium

Cookies are not easy to eat

HOW TO REMOVE EMPTY LINES IN VISUAL STUDIO CODE

Top 10 Node.js Frontend Frameworks To boost Up Your Development Projects

A beginners guide to Shopify Themekit and Schema

shopify developers banner