--no-gui and --external-auth support

[jlevon]

I'd like to run completely headless: if I need to re-auth for whatever reason, I'd like to use --external-auth, but via an interactive run (copy and paste on the terminal). This is like davmail headless mode.

I can't use --local-server-auth as the redirect_url must match the expected one for o365 (so localhost won't work).

Any thoughts?

[simonrob]

There has previously been some discussion about this type of usage, but it is not currently supported because it would need to either block the script or add extra complexity and potential for confusion (e.g., multiple accounts needing authentication simultaneously).

Why wouldn't you just update the redirect_url?

[jlevon]

Again, I can't update the redirect_url, it has to match a set of ones on the server.
In my case I want it to block the script, since I can't do anything with it until I'm authenticated. And if I'm not at the GUI, I'm blocked anyway since I can't access the systray.

[simonrob]

Of course, but what I meant is why not update the configuration of your O365 client to add http://localhost as an option?

[jlevon]

Oh, I think you're asking about the client corresponding to the client_id I'm using. That's because, as far as I was able to tell, I don't have permissions to register such a client that can access the O365 instance - I can't remember what didn't work though.

So I'm re-using davmail's client_id. IIRC some oauth2 providers don't even let you register new clients at all.

(The whole "you have to create your own client_id" thing seems a bit of a bonkers part of oauth2 to me).

[simonrob]

In that case you have three main options, in order of preference:

1. Use a different client ID.

2. Set redirect_uri to the correct value and add redirect_listen_address = http://localhost. Outside of the proxy, map your redirect_uri to 127.0.0.1 (for example, via a hosts file edit), and then use --local-server-auth as normal.

3. Hack around this, replacing the contents of this method with something like the following (which I have not tested in any way), again making sure the redirect_uri value in your proxy configuration file matches what is expected:

Log.info('Please visit the following URL to authenticate account %s: %s' %
         (token_request['username'], token_request['permission_url']))
token_request['response_url'] = input('Please paste the resulting redirection URL: ')
del token_request['local_server_auth']
RESPONSE_QUEUE.put(token_request)

[jlevon]

3. is exactly what I'm asking for - I'm not quite sure why it's a hack, as it's exactly how --external-auth does it right?

Would you take a PR that does this iff --no-gui + --external-auth?

[simonrob]

Not for this particularly hacky way of doing it - it is flawed and not suitable outside of this use-case.

I am happy to consider better ways to achieve this, but not anything that blocks the script or would conflict with log outputs.

[jlevon]

I can't see any other way it could possibly work. I'll keep a fork then, thanks for discussing.

[jlevon]

Oh - would you take a PR to refuse "--no-gui" when "--external-auth" is given, so people aren't misled into thinking this could work?

[simonrob]

Thanks for the suggestion. I actually think this could add further confusion, because using --no-gui without --local-server-auth will similarly not raise any authentication prompts, but wouldn't (and shouldn't) be refused. In general, I think the readme makes it pretty clear that --local-server-auth is the only currently valid option to allow authorisation to work in non-GUI mode.

It is probably worth at some point consolidating the various authorisation options into a single parameter that defaults to interactive mode when a GUI is present, and some sort of stdin-based approach (for example, via prompt_toolkit's patching) when not. However, as explained above, I'm not open to any changes that block the proxy or interfere with log output from other threads – using with multiple accounts is very common, and there are lots of potential issues here.

[simonrob]

I had a look just now at whether the prompt_toolkit approach mentioned previously might work with the proxy. I've committed support for this to the terminal-auth branch.

To use this feature you'll need to either update the proxy's requirements (python -m pip install -r requirements-no-gui.txt) or install prompt_toolkit: python -m pip install prompt_toolkit. Enable it by using the --external-auth flag in --no-gui mode.

Feedback very welcome!

[jlevon]

I know this is incredibly late, so no problem if not, but any chance that code is still around? Thanks.

[simonrob]

Yes - it was merged into the proxy. You can find it when using the --external-auth option in --no-gui mode (as long as prompt_toolkit is installed).

[jlevon]

Oops, didn't think to check - works great, thank you so much for adding this!