API is now the central control point for making authorized
requests. The current architecture is:
* db simply returns all data
* api uses tokens to filter data from db. It includes methods for
returning objects, and HTTP endpoints for return JSON.
* ui calls the api functions to get filtered data.
Also changed order that extractToken looks for tokens. Used to
be cookies then headers then query. Now in reverse, to make it
easier to override, ie for replacing cookies during login.
Required switching to TLS for LetsEncrypt, so I could disable
the HTTP ACME handler. Pretty sure there's a way to keep them
both enabled but this is fine for now.
Allows a few things:
* Can terminate HTTP/2 without the upstream needing to implement
it
* Allows modification of headers in both directions
* Allows logging at the proxy
I had been moving in the direction of implementing a custom SSH
server in golang. That would be pretty easy if using a custom
application protocol, but I want to support tcpip-forward which
looks like it would be a lot more work. It also would be nice to
support generic CLI clients like OpenSSH.
The point of using SSH in the first place is that it's known to be a
solid tunneling solution. To that end, I've decided to rely on
OpenSSH for now, since that program may have tunneled more bits than any
other since the dawn of time. This requires a bit of hackery to generate
SSH keys and place them in authorized_keys (as well as shipping the
private key to the client), but I think this will work well for now.
Plus OpenSSH is already installed on pretty much every server
I'd expect to run boringproxy.
Turns out SSH has robust semantics for opening generic channels.
Looks like I'll be able to set up tunnels without ever needing to
forward ports on the server, since I can connect the channels with
a custom protocol.
Of course I'll eventually want to support generic SSH clients, but
this makes starting much easier.
