I am currently rereading the boringproxy documentation for feasibility for updating selected deployments. Thank you first for providing this new space for in-depth considerations around small scale self-hosting and open protocols. It will greatly support an upcoming v1 release of the tool.
In reading so, I am finding that -client-name could maybe mostly fall-back to the current hostname, if not provided differently (e.g. per user, user@host, … , when started from a systemd @ unit), then making it optional.
Additionally, a -user name is also not mandatory for Web Interface access¹, then why so during authentication (authn) of a client? Is it that this process could rather be considered authorization (authz) instead, for it is also most often a systemic daemon that provides for it, and is a service acting on behalf of a user, an agent so to say, but not an interactive session by them in itself.
Also, there could be a better visual distinction between the display of the server command, and the explanation of the parameter/argument below.
Also, the boringproxy installation page on boringproxy.io does not have a title that reveals more details than the base domain, does not yet offer the new latest binary, and also neither schema.org metadata nor OpenGraph tags or Twitter Cards. It is therefore blinding this Discourse (and social media users linking to it):
These are basically notes to myself as a reminder to investigate interest in these usability simplifications, and to prepare a little PR with the suggested changes.
Footnotes
¹ Don’t know if this is still the case with the newer v0.8 branches, as still currently updating.
Hey @yala! As always your participation in improving boringproxy is greatly appreciated.
These are excellent suggestions.
In reading so, I am finding that -client-name could maybe mostly fall-back to the current hostname, if not provided differently (e.g. per user, user@host, … , when started from a systemd @ unit), then making it optional.
Completely agree. I’ve opened an issue to track this.
Additionally, a -user name is also not mandatory for Web Interface access¹, then why so during authentication (authn) of a client?
This one is actually really annoying. The user information is stored in the token, so it shouldn’t be necessary to provide it separately. I also keep forgetting why this is the case, going in to change it, and then remember the problem, which is this: the API is currently RESTful, so to get clients for a user you GET /users/<username>/client. So the client has to know the user when it builds the request. I need to restructure it so it’s not necessary. It does really have to be REST. Note that this might end up falling under designing a new tunneling protocol, which you can read about here.
Also, the boringproxy installation page on boringproxy.io does not have a title that reveals more details than the base domain, does not yet offer the new latest binary, and also neither schema.org metadata nor OpenGraph tags or Twitter Cards.
It would be nice to add these in, but I’m not very familiar with them. I’ve open another issue though.
Thank you for picking up the suggestions. I will also have a look in the other conversation: Instead of SSH tunnels, some kind of ad-hoc Wireguard bridge comes to my mind, but still processing …
many of these suggestions have been implemented. As the original posting here was about documentation, I am also including a Pull Request that makes the website fit for it:
In upgrading there, we may also seek to consider the ideas here, to answer for needs of consistency between documentation and program.
