--- Comment #15 from Mateusz Polrola <mateusz.polrola(a)gmail.com> ---
One thing I am uncertain about is the use of "refresh
token" in the identity
provider name. It's surprising that the "oauth2" backend installs a
providerrefreshtoken.so. I think I would prefer to have refresh[_-]?token
replaced by simply oauth2. Agreed?
The handling of the command-line-only case without a permanent config
missing. It's a bit hard to test because it only triggers when we need a new
refresh token, and I haven't seen that happen. I suspect what would happens
is an exception from a non-writable config node, which is covered by the
general catch all.
I know that it's hard to trigger refresh token update (I also haven't seen that
happen), to test refresh token update code during development I was just
triggering update by myself each time that I was receiving access token.
I have also not tested how a failure to get an OAuth2 bearer token
reported. In particular I cannot guarantee that a sync fails with an error
that indicates an authentication problem.
Here is how such error looks like when exporting vcards
[INFO] SoupTransport Failure: https://accounts.google.com/o/oauth2/token
libsoup: Bad Request
[ERROR] OAuth2 request failed with error: invalid_grant
[ERROR] addressbook: error code from SyncEvolution access denied (remote,
status 403): logging into remote service failed: OAuth2 request failed with
[ERROR] addressbook: reading items
You are receiving this mail because:
You are on the CC list for the bug.