Add authorisation via CLI

[ivanfdez]

Added command line authorization, new option is --manual-auth

This option prints the url to externally authenticate in a browser. After a successful authentication we will have the authorization code

[simonrob]

Thanks for this pull request. I'm afraid I'm not able to accept it because it completely changes the behaviour of the proxy, causing it to block while waiting for a single account's username/password on launch. The switch to urn:ietf:wg:oauth:2.0:oob is also a major change in behaviour (and not one that is universally supported).

However, I do see the benefit of being able to monitor the proxy's log for authentication URLs and deal with them completely separate to the proxy itself. So, I think a better approach would be to support this usage via a local web server to intercept the http://localhost redirection. This can be unreliable, hence why it is not currently the way that authentication is handled, but it would provide a way of supporting this use-case. I'll look into this when I get chance.

[ivanfdez]

As you can check with (redirect_uri = urn:ietf:wg:oauth:2.0:oob) perform the authorization with the code through CLI, but at the same time it makes it incompatible with GUI.

For my specific case it works, since I am not going to use the GUI.

[simonrob]

Yes - I'm not suggesting it doesn't work, just that it isn't good as a default in the configuration file for the reason you suggest: it means the GUI method will fail. The underlying proxy code will work with both approaches, of course.

I'm glad you've found a way that works for you - I'll update this once I've had time to look at the alternative I mentioned.

[simonrob]

I've just committed a potential option to support this in the local-server-auth branch.

Running the proxy with the new option --local-server-auth will print authentication URLs to the log, and handle the local redirect itself. You will need to edit your account's redirect_uri to, e.g., http://localhost:8080 to allow the proxy to receive the authentication response.

In my view this is a more suitable way to handle this use-case because it doesn't block, and doesn't require input in the terminal. Unless there are any major issues, I'll merge this at some point soon.

[simonrob]

af30907 supersedes this approach, so I'm closing this request. Thanks for the suggestion that led to this new mode.