Hey @yala! As always your participation in improving boringproxy is greatly appreciated.
These are excellent suggestions.
In reading so, I am finding that
-client-namecould maybe mostly fall-back to the currenthostname, if not provided differently (e.g. per user, user@host, … , when started from asystemd@ unit), then making it optional.
Completely agree. I’ve opened an issue to track this.
Additionally, a
-username 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
latestbinary, 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.