[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#72358: 29.4; oauth2.el improvements
From: |
Xiyue Deng |
Subject: |
bug#72358: 29.4; oauth2.el improvements |
Date: |
Wed, 31 Jul 2024 00:43:34 -0700 |
Björn Bidar <bjorn.bidar@thaodan.de> writes:
> 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.
It currently depends on this modified oauth2.el. Once the patches are
accepted I'll post it in a separate bug.
--
Xiyue Deng
- 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