sgw

A tiny, dead-simple gateway and reverse-proxy.

sgw issues a cookie with a random value to each device that visits the gateway. Once a device is approved by an admin, it's allowed through the gateway to the services behind it.

How it works

1. An unknown device requests any route, sgw sets a cookie and responds with a holding page.
2. The holding page polls sgw, which places the device on a waitlist.
3. An admin reviews the waitlist at /sgw/admin and may approve the device.
4. Once approved, the device's next poll succeeds and it is proxied through.

Running sgw

Build the binary:

go build

Create a config file (sgwconfig.json, read from the working directory):

{
  "routes": [
    { "prefix": "/notes/", "destination": "http://localhost:8080" },
    { "prefix": "/media/", "destination": "http://localhost:8081" }
  ],
  "tls": {
    "domain": "gateway.example.com"
  }
}

• routes are net/http ServeMux patterns mapped to backend URLs.
• tls, when present, serves HTTPS on 443 with certificates obtained automatically from Let's Encrypt, and redirects HTTP to HTTPS. When absent, sgw serves plain HTTP on port 7490 for local use.

Finally:

./sgw serve

Approving devices

The first admin device is bootstrapped from the command line. Visit the gateway from a browser, copy the device hash shown on the holding page, and on the server (from sgw's working directory) run:

./sgw approve --admin <hash>

An admin device can then approve all subsequent devices from the dashboard at /sgw/admin.

Deployment notes

• sgw reads sgwconfig.json and store.txt, and caches certificates in certs/, all relative to its working directory.
• Let's Encrypt issuance requires the domain's A record to point at the host, and ports 80/443 to be reachable from the internet.
• certs/ and store.txt are obviously worth backing up.