1.5 fails to authenticate (Debian testing)

[vrs]

Upon granting access, I get the following output:

Please visit this URL to authorize this application: <snip>
Traceback (most recent call last):
  File "/usr/bin/gmi", line 24, in <module>
    g.main ()
  File "/usr/share/lieer/lieer/gmailieer.py", line 418, in main
    args.func(args)
  File "/usr/share/lieer/lieer/gmailieer.py", line 618, in pull
    self.remote.get_labels()  # to make sure label map is initialized
    ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/lieer/lieer/remote.py", line 138, in func_wrap
    self.authorize()
  File "/usr/share/lieer/lieer/remote.py", line 495, in authorize
    self.credentials = self.__get_credentials__()
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/lieer/lieer/remote.py", line 560, in __get_credentials__
    self.__store_credentials__(credential_path, credentials)
  File "/usr/share/lieer/lieer/remote.py", line 509, in __store_credentials__
    storage.write(credentials.to_json())
                  ^^^^^^^^^^^^^^^^^^^
AttributeError: 'Credentials' object has no attribute 'to_json'

After that, I have an empty .credentials.gmailieer.json file and further runs result in this:

Traceback (most recent call last):
  File "/usr/bin/gmi", line 24, in <module>
    g.main ()
  File "/usr/share/lieer/lieer/gmailieer.py", line 418, in main
    args.func(args)
  File "/usr/share/lieer/lieer/gmailieer.py", line 618, in pull
    self.remote.get_labels()  # to make sure label map is initialized
    ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/lieer/lieer/remote.py", line 138, in func_wrap
    self.authorize()
  File "/usr/share/lieer/lieer/remote.py", line 495, in authorize
    self.credentials = self.__get_credentials__()
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/lieer/lieer/remote.py", line 525, in __get_credentials__
    credentials = Credentials.from_authorized_user_file(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/google/oauth2/credentials.py", line 193, in from_authorized_user_file
    data = json.load(json_file)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/__init__.py", line 293, in load
    return loads(fp.read(),
           ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

After deleting .credentials.gmailieer.json and rerunning, I get the first trace again.

This seems less like a migration issue (#257) and more like it being broken. Are there any additional states I should reset?

% apt show lieer
Package: lieer
Version: 1.5-1

[windo]

You need https://github.com/googleapis/google-auth-library-python/commit/bfb1f8cc8a706ce5ca2a14886c920ca2220ec349 which isn't in Debian version of python3-google-auth (Debian has 1.5.1 which is from 2018).

I just applied that patch (well, I just copy-pasted the function) locally which was enough to get it to work. But I keep having to re-authenticate every time I run gmi, which might I wonder if it could be due to needing a newer version for some token refresh change or something.

[windo]

OK, I figured out that the constant re-authentication happens because of the credentials.expired check here: https://github.com/gauteh/lieer/blob/master/lieer/remote.py#L530

With the packages in debian, credentials.expired is always False when no expiry time is set, which is always the case when loading the saved credentials from a file. I just removed that check and it seems to be better. It's not clear to me what that condition is supposed to protect against, maybe it really isn't needed at all?

[gauteh]

Maybe it is something leftover. If you want please submit a pull request.

fre. 13. okt. 2023, 15:18 skrev Siim Põder @.***>:

OK, I figured out that the constant re-authentication happens because of the credentials.expired check here: https://github.com/gauteh/lieer/blob/master/lieer/remote.py#L530

With the packages in debian, credentials.expired is always False when no expiry time is set, which is always the case when loading the saved credentials from a file. I just removed that check and it seems to be better. It's not clear to me what that condition is supposed to protect against, maybe it really isn't needed at all?

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

[gauteh]

I'm hesitant to remove the check in case it breaks newer versions of the lib. At least until someone confirms it works on newer versions as well. The debian lib is getting quite old.

[euglevi]

In Debian, I solved this by installing lieer in a virtual environment rather than through the deb package. This solves the lib dependency issue.

[vrs]

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053227

[gongzhitaao]

OK, I figured out that the constant re-authentication happens because of the credentials.expired check here: https://github.com/gauteh/lieer/blob/master/lieer/remote.py#L530

With the packages in debian, credentials.expired is always False when no expiry time is set, which is always the case when loading the saved credentials from a file. I just removed that check and it seems to be better. It's not clear to me what that condition is supposed to protect against, maybe it really isn't needed at all?

I suddenly went into the same issue here. Likewise, I commented out the whole check if not credentials or not credentials.valid: and it works for me now.

[gauteh]

Think this is fixed

[vrs]

Can confirm this is fixed for me.