Migrate to non oob oauth before October

[gauteh]

Will be blocked on October 3.

[tohojo]

So any plans for this? October 3rd is less than a week away now :)

[gauteh]

No, I don't have capacity atm, here are some links I got:

• https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html
• https://developers.google.com/identity/protocols/oauth2/resources/oob-migration

[tohojo]

Alright, thanks for the pointers. I guess I'll take a look. It seems that the oauth2client library that lieer is using is deprecated in its entirety; do you have any opinions on whether it's more feasible to fix up the auth flow without replacing the library, or if it's better to just switch to one of the suggested alternatives while we're fixing up things? :)

[gauteh]

Definitely better to switch to something that is maintained :)

-- gaute

On Wed, Sep 28, 2022 at 2:07 PM Toke Høiland-Jørgensen < @.***> wrote:

Alright, thanks for the pointers. I guess I'll take a look. It seems that the oauth2client library that lieer is using is deprecated in its entirety; do you have any opinions on whether it's more feasible to fix up the auth flow without replacing the library, or if it's better to just switch to one of the suggested alternatives while we're fixing up things? :)

— Reply to this email directly, view it on GitHub https://github.com/gauteh/lieer/issues/215#issuecomment-1260807643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN366RTG37XCCRSTQQJOLWAQYHRANCNFSM5VA7XJYA . You are receiving this because you authored the thread.Message ID: @.***>

[mjg]

The funny thing is that they tell you to migrate to "Loopback IP address", which in turn is deprecated for most platforms (except desktop). I was hoping for a more permanent looking alternative to come up before next week ... Note that oob will continue to work for apps in "test status", so if all else fails one should be able to use unchanged lieer with a personal api key (and weekly refresh, probably).

[gauteh]

Not sure if we ever moved from test. Pretty sure it is no longer possible to create a similar key that public lieer has at the moment.

[mjg]

https://github.com/getmail6/getmail6/blob/master/getmail-gmail-xoauth-tokens might be all that we need, but according to SO the expire times are 1h :|

[tohojo]

I think it may be possible to refresh the token without user interaction, though, in which case that doesn't have to be such a big deal (just check and refresh it on each run). I'll experiment a bit with it and see how it works.

Side note, the documentation of that project (getmail6) recommends just using an app password instead of oauth; any reason lieer can't do that?

[gauteh]

We already refresh the tokens, if you don't sync regularly you have to reauth. Does app password work with the api? Also I think many orgs close app passwords.

fre. 30. sep. 2022, 17:08 skrev Toke Høiland-Jørgensen < @.***>:

I think it may be possible to refresh the token without user interaction, though, in which case that doesn't have to be such a big deal (just check and refresh it on each run). I'll experiment a bit with it and see how it works.

Side note, the documentation of that project (getmail6) recommends just using an app password instead of oauth; any reason lieer can't do that?

— Reply to this email directly, view it on GitHub https://github.com/gauteh/lieer/issues/215#issuecomment-1263696862, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN367ST2OWJR2IDBGPHXTWA3677ANCNFSM5VA7XJYA . You are receiving this because you authored the thread.Message ID: @.***>

[tohojo]

Does app password work with the api?

No idea; was hoping you knew ;)

Anyway, seems like it's a lot of work to detangle the oauth bits from the rest of the code anyway, so probably better to keep it. Also, it seems the oauth2client library already has support for the localhost redirection flow; all we need to do is enable it by passing in the right args. The patch below is all it took for me to get lieer to switch to that. Only drawback seems to be that things will only work if you can actually complete the auth flow on the local machine (so the redirect to localhost works).

(Side note: it seems gmi init is broken - it either complains that the maildir already exists, or if it doesn't the notmuch2 library barfs on not being able to find the notmuch database)

diff --git a/lieer/gmailieer.py b/lieer/gmailieer.py
index 60aa3cef37e2..9296f9b2fecc 100755
--- a/lieer/gmailieer.py
+++ b/lieer/gmailieer.py
@@ -145,6 +145,15 @@ class Gmailieer:
     parser_auth.add_argument ('-f', '--force', action = 'store_true',
         default = False, help = 'Re-authorize')

+    # These are taken from oauth2lib/tools.py for compatibility with its
+    # run_flow() method used during oauth
+    parser_auth.add_argument('--auth_host_name', default='localhost',
+                        help='Hostname when running a local web server.')
+    parser_auth.add_argument('--auth_host_port', default=[8080, 8090], type=int,
+                        nargs='*', help='Port web server should listen on.')
+    parser_auth.add_argument('--noauth_local_webserver', action='store_true',
+                        default=False, help='Do not run a local web server (no longer supported by Google).')
+
     parser_auth.set_defaults (func = self.authorize)

     # init

[tohojo]

BTW, it's not clear to me whether the policy change at Google only affects new auth flows, or if they lock out all existing sessions as well (i.e., prevent token refresh)?

[jindraj]

@tohojo: now it's clear… Today my credentials stopped working.

I've edited the file to match your patch. I've tried to do gmi auth -c .credentials.gmailieer.json -f to force reauth. but as you mentioned in your earlier message

things will only work if you can actually complete the auth flow on the local machine (so the redirect to localhost works).

I need to go through gmi init. It opens browser, I mark checkbox that I trust the developer, mark all 3 scopes and then I'm stuck on the link looking like this http://localhost:8080/?code=4/...Q&scope=https://www.googleapis.com/auth/gmail.readonly%20https://www.googleapis.com/auth/gmail.labels%20https://www.googleapis.com/auth/gmail.modify

gmi --logging_level DEBUG init -c ~/Downloads/credentials.json myemail.gmail.com
initializing repository in: /Users/jindraj/.mail/gmail..
/opt/homebrew/lib/python3.10/site-packages/oauth2client/_helpers.py:255: UserWarning: Cannot access /Users/jindraj/.mail/gmail/.credentials.gmailieer.json: No such file or directory
  warnings.warn(_MISSING_FILE_MESSAGE.format(filename))
auth: using user-provided api id and secret

Your browser has been opened to visit:

    https://accounts.google.com/o/oauth2/auth?client_id=MYCLIENTID&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2F&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.readonly+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.labels+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.modify&access_type=offline&response_type=code

If your browser is on a different machine then exit and re-run this
application with the command-line parameter

  --noauth_local_webserver

init: repository is set up, but authorization failed. re-run 'gmi auth' with proper parameters to complete authorization

Any suggestions what am I doing wrong?

EDIT: I added myself as in Test users in the https://console.cloud.google.com/apis/credentials/consent?project=PROJECTNAME - that made the trick apparently.

[archer-65]

Any news about this issue?

[mjg]

After a system upgrade, I noticed a possibly relevant change. Background: I use lieer with the supplied credentials (unchanged) but oauth for msmtp and mbsync with my own credentials (this what I describe). This workflow used to give me a URL to navigate to manually, required clicking through a few steps and pasting a token to the command line input again. Now, while the URL is still output, the browser opens automatically, and after I click through the final step the token is captured automatically. So it seems as if the same google library calls which produced oob before now produce the localhost redirections for the migrated workflow. I have not checked version differences yet, but here are the main code pieces I am using:

import google_auth_oauthlib
import google.oauth2.credentials
import google.auth.transport.requests
...
    # init, this is what changed in behaviour
    scopes = "https://mail.google.com/" # for SMTP/IMAP
    credentials = google_auth_oauthlib.get_user_credentials(scopes, ...)

    # refresh
    credentials =  google.oauth2.credentials.Credentials(
    credentials.refresh(google.auth.transport.requests.Request())