Ein Baum und seine Abenteuer



Go based proxies for developing mobile websites on corporate WiFis

You might know this scenario:

We would really love to debug the web-app on an actual phone but they way our corporations WiFi is set up just won't allow it…

When networks become a show stopped for development.
When networks become a show stopped for development.

If you do, stay tuned because in this blog post we will examine how we as developers can handle tightly secured WiFi Networks and still get all the connectivity we need.

We will set out by exploring a detailed, real world scenario and then explore a solution using hotspots and Go based proxies.

An exemplary situation

Recently we were developing a Capacitor based hybrid web application. To really debug that you run a webserver on your laptop and connect your phone via WiFi. Only trouble: on our corporations WiFi phones get isolated for security reasons.

Phones get isolated for security reasons!

Luckily the isolation problem can quite easily be solved by connecting your laptop with the internet via ethernet and using the Laptops WiFi to opening up a hotspot. Just make sure to secure that with a strong password!

Sadly, that cut our laptops off from the internal networks which we had to reach again by connecting our laptops to the companies VPN (jup, ethernet only went to the public internet). While the hotspot handed the internet connection through to the phone it doesn't do the same magic for the VPN connection. So, how do we now get this connection through to our phones?

We need the internal network because the phone needs to connect to the deployed test backend, available on the companies internal network that our laptops connect to using VPN.

Muscle emoji
Muscle emoji

Proxies to the rescue

Handing traffic around on a network is something we as web developers are familiar with. Often time you need an NGINX to hand requests from an entry URL to the right internal service running on a different machine (or to dockerize a web app). That is called a proxy.

As just mentioned we could setup an NGINX or similar on our laptops and use that as a proxy. And this does work. However it makes it more difficult to check the solution into version control. A better maintainable version is to write a simple proxy in your language of choice. We choose Go.

package main

import (
    "github.com/elazarl/goproxy"
    "log"
    "net/http"
)

func main() {
    proxy := goproxy.NewProxyHttpServer()
    proxy.Verbose = true
    log.Fatal(http.ListenAndServe(":9090", proxy))
}

That is all the code you need to now run go run proxy.go and start a proxy on your machine.

Green light for our traffic thanks to proxies.
Green light for our traffic thanks to proxies.

On your phone you now need to tell it to not only connect to your laptops hotspot but also use a proxy. For that you likely need your laptops IP within the hotspot (it will likely always assign itself the same one) as well as the port (here: 9090) to set that up.

With this you are now ready to finally do development on your phone.

Conclusion

Today we looked at how a simple proxy in Go can help us to develop in tightly secured corporate networks. With just a few lines of code and a bit of setup you can get going.

Now, go out and build something awesome ✨


Reflection

There is one obvious question here: Is this a good idea??!?

I am so glad that you asked. And in truth I am not sure. It surely feels like a hack and it is one. We are basically getting around a security measurement established for a good reason. I would encourage you to see the practices here as a short term solution and to pick up a discussion with you management and IT about a long term solution.

Any comments and ideas for better solutions are highly welcome and appreciated.

Author

Hendrik

I am a JavaScript Enthusiast and developer for the fun of it!
Here I write about webdev, technology, personal thoughts and anything I finds interesting.

More about me

Read next

Dockerizing modern web apps

These days everything is shipped in containers, even software.
These days everything is shipped in containers, even software.

Most websites these days are Single Page Applications (SPA for short) where a single entry file handles all routes that a user might visit. Swept up in the ongoing trend of hosting in the cloud you might find yourself needing to “dockerize” your SPA. That is to say wrap it inside a Docker image and run it as a container.

Technical debt and dirty dishes

Technical Debt is a lot like doing your dishes.
Technical Debt is a lot like doing your dishes.

Working with Engineers you probably heard the term "Technical Debt". But what is this "debt" Engineers keep referring to? Just an excuse to push features further out? Join us on a journey to understand what Technical Debt has to do with doing your dishes and paying back your student loans.

Daily Note navigation in Obsidian using Dataview

Navigation between daily notes in Obsidian
Navigation between daily notes in Obsidian

Daily notes in Obsidian are ephemeral, they matter most for the day there were written and maybe the days surrounding them. But, after a week, we hardly ever refer back to them. If something truly mattered, we probably pulled it out to another note.

That being said, I often find myself wanting to refer to yesterdays note. And Obsidian doesn't provide a native way to get to yesterdays note. My current solution to this is to add links to the last and next daily note into every daily note via a template.