It was using the user that made the request as the user to get
the list of clients from, which meant for example if an admin made
the request, you were limited to the names of clients that the
admin also used.
This lets you use a proxy for connecting to the SSH server, which
is useful on networks that block SSH/port 22. For example you can
use the boringproxy tuntls command to create a proxy that will
tunnel the client's SSH connections over TLS to the server.
It's all very meta and forces at least double encryption, but it
could be useful.
Previously it was RESTful and required both a user and client
name in order to PUT new clients. Now this information is taken
from the token if possible (user is always available, client name
may not be) and a simple POST /clients endpoint is provided.
Added the ability to scope tokens to a specific client. If
enabled, this has the affect of limiting the token to being used
to list tunnels for that specific client. It can't be used for
the web UI or for any state-changing actions such as creating
new tunnels.
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.
