GNU bug report logs - #72358
29.4; oauth2.el improvements

Previous Next

Full log

View this message in rfc822 format

From: Xiyue Deng <manphiz <at> gmail.com>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 72358 <at> debbugs.gnu.org
Subject: bug#72358: 29.4; oauth2.el improvements
Date: Wed, 31 Jul 2024 00:43:34 -0700

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

> Xiyue Deng <manphiz <at> gmail.com> writes:
>
>> Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
>>
>>> Xiyue Deng <manphiz <at> gmail.com> writes:
>>>
>>>> The fourth patch may need a bit of background: oauth2.el (optionally)
>>>> uses plstore to save authentication data for future reuse, and the
>>>> plstore id for an account is computed using a combination of `auth-url',
>>>> `token-url', and `scope'.  However, this combination of data doesn't
>>>> guarantee uniqueness for accounts for a same provider, e.g. for Gmail,
>>>> the three parameters are the same for different accounts, and hence
>>>> storing a second account information will override the first one.
>>>
>>> Would it make sense to plug OAuth2.el into auth-source to store the
>>> authentication token safely inside an existing credential storage?
>>>
>>> Various applications already do so when using the native credential
>>> storages such as Freedesktop.org or the macOS keyring.
>>
>> As I mentioned to Robert, I do have another addon to do exactly this,
>> though through an awkward advice.  Would be great if auth-source can
>> make use of oauth2.el and handle that more gracefully.  I'll file
>> another bug to explore options once this one is done.
>
> Care to post this advice? It's not an optimal solution but better than
> nothing in the interim.

It currently depends on this modified oauth2.el.  Once the patches are
accepted I'll post it in a separate bug.

-- 
Xiyue Deng

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.