[Users] expired OAuth2 token treated as still fresh, will not update

Dan N dhn2-linux at stanfordalumni.org
Mon Nov 7 20:49:42 UTC 2022


On Mon, 07 Nov 2022 17:50:11 +0000
"David Fletcher" <David at megapico.co.uk> wrote:
> 
> Hi Dan,
> 
> This is strange. The OAUTH2 tokens are stored in the password database on
> a per account basis so there should not be any interaction between the
> accounts.
> 
> There is a function in the source (oauth2.c) which decides if the tokens
> are still fresh:
> if (expiry >  (g_get_real_time () / G_USEC_PER_SEC)){
> 
> The stored expiry time is actually generated locally on your machine to
> avoid time zone issues. So if Google says the token has a life of 3600
> seconds (1 hour) that is stored using g_get_real_time () /
> G_USEC_PER_SEC) + 3600.
> 
> I'm not sure how that is going wrong unless there's something wrong
> with your passwordstorerc file? Looking at my system just now changes to
> this file are cached in memory until you close Claws. I'm not sure how
> that would go wrong.
> 
> David.

Thanks for the info.

Yesterday, after waiting and retrying to update for an hour, I went ahead
and forced a token update the hard way.  I ran gdb with my debugging
version of claws-mail, put a breakpoint on the line before that expiry
check, and when triggered I printed the expiry value, set it to 0 and
continued.  The token then updated like it should.

The old token expiry still had 1200 seconds left, so almost 3 hours since
it was created.  Could have been anything from library bug to i/o buffer
corruption, etc., especially since it only affected 1 account and not the
other.  Will ignore unless it happens again.


More information about the Users mailing list