This is useful for when you want to use boringproxy more like a
normal reverse proxy, ie if boringproxy and your service are on
the same machine, you can just use the port of the service as the
tunnel port and boringproxy will forward directly to it without
using SSH.
This would normally be used with no client set.
This is a bit of a hack. Problem is if the server is restarted
with a different SSH port, all the tunnels in the db have the
incorrect port setting, so we're overriding at runtime.
Really should update all the db entries but that's messy too.
Probably the real solution is to decouple runtime tunnel settings
from permanent tunnel settings, and only store the permanent ones
in the db.
* The CSS styles were leaking information about tunnels, even for
things like the login page, which can be sent to anyone.
* Tokens could be created for any user by any user.
Just needed to add an option to allow external connections to the
ports from the server, then set the proper values in the
authorized_keys file and on the client.
Allows tunnels to specify what address the client with connect to
for upstream connections.
Also changed the tunnel-adder UI.
Also fixed a bug where invalid domains would crash. Needed to
properly return an error dialog.
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.
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.
