davmail
davmail copied to clipboard
Bootstrapping oauth2 token
I am running davmail in headless (server) mode and using the O365Manual authentication mode. However, this requires some clunky switching back and forth between background and foreground when a new token needs to be obtained. The procedure seems to be:
- kill background instance of server
- start foreground instance of server
- prompt mail agent to send request to server to trigger authentication process
- copy/paste URLs back and forth
- kill foreground instance of server
- start background instance of server
- mail agent can then send requests silently again
Other oauth2 implementations that I've used provide a standalone script to obtain tokens (examples: https://github.com/tarickb/sasl-xoauth2/blob/master/scripts/sasl-xoauth2-tool.in, https://github.com/rlonstein/getmail/blob/master/getmail-gmail-xoauth-tokens, https://github.com/harishkrupo/oauth2ms). This would avoid the need for starting/stopping the server, or any foreground instances at all, or involving the mail agent. Whenever the server reports that it can no longer refresh the current token, we can just run the standalone script and get a new token.
In this case, the davmail.properties file could take arguments pointing to the location of each user's token file, rather than directly inserting the encoded refresh tokens.
I recognize that this is a non-trivial feature request, but it would make headless mode much smoother.
Not a full answer to you request, but I added a -token command line option to just open the O365InteractiveAuthenticator and print refresh token on console
If you combine davmail -token with the optional setting: davmail.oauth.tokenFilePath to set a separate file path for tokens you should be able to get seamless update of refresh tokens.
Note that for windows users I also published a powershell script as an alternative to davmail -token at: https://github.com/mguessan/o365psauth => uses native webview2 (Chromium Edge) => supports windows single sign on with -SSO option
Thanks for adding this feature!
I tried this with the new 6.2.2 build. davmail -token works, but once it refreshed the token, it stopped the already-running background instance of davmail and I had to restart it.
This also only works with the interactive authentication, which is slow when davmail is deployed on a headless server. Is it possible to make this work with O365Manual authentication, where the actual login can be conducted on a different machine?
I tried this with the new 6.2.2 build.
davmail -tokenworks, but once it refreshed the token, it stopped the already-running background instance of davmail and I had to restart it.
That doesn't make any sense. How can davmail -token stop the already-running background instance of davmail? That's not the intention, surely, so it's a bug if that's what's happening.
Can you provide step-by-step instructions to reproduce this, @kpedro88 ?
Do you have davmail.oauth.tokenFilePath and davmail.oauth.persistToken set in your .davmail.properties file?
davmail.propertiescontainsdavmail.oauth.tokenFilePathanddavmail.oauth.persistToken=truedavmail .davmail/davmail.properties >& log_davmail.log &davmail .davmail/davmail.properties -token
I just tried again and it didn't stop the background process this time. The first time, I saw this after finishing step 3:
[1]+ Stopped davmail .davmail/davmail.properties &> log_davmail.log
Unfortunately the log file got overwritten. I'll keep checking to see if it happens again.