Go based proxies for developing mobile websites on corporate WiFis
Tags: webdev, javascript, productivity
Published: 2018-10-02 14:56:56

---
title: Go based proxies for developing mobile websites on corporate WiFis
published: true
cover_image: https://thepracticaldev.s3.amazonaws.com/i/21s4w8nib7nsqiasifht.jpg
description: Sometimes well meaning intentions keep us from getting work done, let's change that.
tags: webdev, javascript, productivity
---

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…

![](https://thepracticaldev.s3.amazonaws.com/i/1d2vwn7kap3i0brauahw.jpeg)
<figcaption>When networks become a show stopped for development.</figcaption>

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.

![](https://thepracticaldev.s3.amazonaws.com/i/7u7zaxhfkhckw5i43zbn.png)

## 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.

```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.

![](https://thepracticaldev.s3.amazonaws.com/i/cccgwvbe3oro7kk2fib4.jpeg)
<figcaption>Green light for our traffic thanks to proxies.</figcaption>

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.