On Wed, Jun 13, 2018 at 7:00 PM Kevin J. McCarthy <[email protected]> wrote:
> On Tue, Jun 12, 2018 at 12:56 PM Brandon Long <[email protected]> wrote: > > And the updated patch. I don't know how to make git give me a single > > patch of the entire change, so this is my three local commits appended > > together, ie with git format-patch origin --stdout > > On Tue, Jun 12, 2018 at 02:15:28PM -0700, Brandon Long wrote: > > Ah, and now with support for that for smtp as well. This does make some > of > > the smtp-auth stuff compiled in even without sasl support. > > > > And works with the following settings: > > set smtp_authenticators="oauthbearer" > > set smtp_url="smtps://[email protected]@smtp.gmail.com:465" > > set smtp_pass=`/path/to/oauth2.py [email protected] > > --client_id=<client-id>.apps.googleusercontent.com > > --client_secret=<client-secret> --quiet --refresh_token=<refresh-token>` > > I've pushed these up as two commits. > > Right now I'm not in a position to actually test the OAUTH support, but > I figure the best way to do so is push it up and let other people try. > > One concern I have with the smtp support is that smtp_pass will only be > invoked once during startup. I think you mentioned the token is only > good for about an hour, so that would lead to failure after an hour of > running mutt right? > Hmm, Gmail will also only let the imap connection work for an hour or so before dropping it, and the re-connection will fail for the same reason. I'm not sure of a good solution to this. One solution would be a mechanism for delayed evaluation of the config options, the other would require more advanced support of OAUTH2, where we would have separate config entries for the various bits (client-id, client-secret, refresh-token and refresh-url) and actually do the https fetch in the code to create the refresh token. It would hard-code using OAUTH2 to get the token, which is probably fine (I'm not sure how many places have an alternative way to get the tokens like we do internally at Google), and we would need to potentially include a json parser and https fetcher in mutt to do that. As for changes to the config handling, I could add new smtp_oauth_token_command/imap_oauth_token_command config vars, and do the evaluation in-line with that, that's probably the cleanest way to handle this as specific to this issue and not try for larger changes. It also makes a certain amount of sense, since access_tokens should really be dynamic, having one without an expiration may be possible under the spec but is probably discouraged. Brandon
