[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#72358: 29.4; oauth2.el improvements
From: |
Björn Bidar |
Subject: |
bug#72358: 29.4; oauth2.el improvements |
Date: |
Wed, 31 Jul 2024 00:51:52 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Xiyue Deng <manphiz@gmail.com> writes:
> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Xiyue Deng <manphiz@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.
- bug#72358: 29.4; oauth2.el improvements, (continued)
- Message not available
bug#72358: 29.4; oauth2.el improvements, Björn Bidar, 2024/07/30
Message not available
Message not available
bug#72358: 29.4; oauth2.el improvements, Andrew Cohen, 2024/07/31