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.
Before we were pre-generating a DNS request ID every time the
add tunnel page was visited. Now we have a separate endpoint for
generating the IDs only after the user indicates they actually
want to perform a TakingNames.io domain request.
Removed unused CssId and moved members that should eventually be
removed from the API surface (ie internal values) to be together
so they're easier to identify later.
TakingNames.io now provides bootstrap domains, which simply
creates an A record based off the ip address of the requesting
server, without requiring any authorization. This allows
boringproxy to always use HTTPS, even when getting the admin
domain.
The requests themselves now must be retrieve from the boringproxy
server by TakingNames.io, over HTTPS. This provides several
security benefits:
* You can tell the user the request is coming from a specific
domain.
* Requests are tied to an ephemeral request-id, to prevent
prebuilt phishing links.
There is currently a single hard-coded exception for setting a
single A record for an IP address. This is needed for
bootstrapping a service that doesn't have any certs yet (ie the
boringproxy admin domain), and will need to display a big scary
message to users.
When using TakingNames.io for getting a domain for a new tunnel,
previously it redirected to the public IP of the server over HTTP.
Now uses the admin domain over HTTPS.
The UI was originally written using fancy HTML checkbox toggle
hacks in order to make the UI very fast. It's cool but complicated
and difficult to change. In order to make updates to the UI more
quickly, I'm changing it to use traditional HTML with full page
reloads for navigation. It's not as fast but much simpler.
* 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.
Not sure the feature is boring enough to keep. There are some tricky
things that still need to be solved like figuring out how to let
tunnels share the same public key, since the OpenSSH server seems to
only pick up the first instance of each key in the authorized_keys
file.
Also, what happens if someone wants to use their normal SSH key for
the server for a boringproxy tunnel. I could easily introduce a bug
that would lock someone out of their server in certain corner cases.
I think adding the ability to download the private key for each tunnel
will handle most cases for now.
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.
Needed to change HTML architecture to inline multiple independent
copies of the menu. There might be a cleaner way to do this, but
it will work for now.
Learned about the :target CSS selector, which can be used to
replace content depending on the current URL hash. This allows
making a sort of single page app without JavaScript.
Currently experimenting with returning all the pages in a single
request, then switching between them with :target. Seems to be
working quite well so far.
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.
