Better, unified OAuth handling
Categories
(Thunderbird :: General, enhancement)
Tracking
(relnote-thunderbird 135+, thunderbird_esr128 wontfix)
People
(Reporter: darktrojan, Assigned: darktrojan)
References
Details
Attachments
(7 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
We have multiple consumers of OAuth2 and they all do things in different ways. I'm not really happy with any of them and I'm especially not happy that there's not one unified piece of code that handles it all. This is a medium-term project to fix that.
- Mail protocols use the
OAuth2Module
which handles token saving/retrieval and interaction with the async authentication system. - CardDAV generally does the same thing, but not initial discovery and set-up of address books. That handles saving tokens itself.
- CalDAV does it very differently, there is a subclass of
OAuth2
for each supported provider and they handle token saving/retrieval through the calendar's system for that. There's also multiple historic formats for storing CalDAV OAuth tokens.
The first steps here will be to reform OAuth2Module
and OAuth2Providers
so that they handle multiple scopes better. The code was originally intended for only a single scope but we hacked multiple scopes into it and it doesn't work very well.
Then we'll change CardDAV and CalDAV to use the same code so that any further changes only need to be made once. I've filed bug 1927971 to find out more about CalDAV's tokens in the wild, so we'll need to wait until we have some useful information from that.
Finally I think we can overhaul the whole system and create a better interface for getting what we need. But that's a fair way off yet.
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Comment 1•3 months ago
|
||
Assignee | ||
Comment 2•3 months ago
|
||
I've changed getHostnameDetails
to take an optional second argument, and return a list of
required scopes (based on the new argument) as well as a list of all scopes. This way we can
better determine if we have all of the scopes we need to complete the current action.
Assignee | ||
Comment 3•3 months ago
|
||
… and only update it when it actually changed.
Assignee | ||
Comment 4•3 months ago
|
||
Assignee | ||
Comment 5•3 months ago
|
||
This removes the last traces of the Lightning oAuth client for Google calendars. Some users will
have to reauthenticate but it's a very small fraction of users.
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 6•2 months ago
|
||
Will this allow us to delete tokens when we no longer need them? It would be great if we could update our privacy policy to include more reassuring wording on that matter...
Assignee | ||
Comment 7•2 months ago
|
||
Assignee | ||
Comment 8•2 months ago
|
||
Assignee | ||
Updated•2 months ago
|
Comment 10•2 months ago
|
||
Assignee | ||
Comment 11•24 days ago
|
||
Closing this. There are still things I want to do but I'll open a new bug for them.
Release Note Request (optional, but appreciated)
[Why is this notable]: This has potential to break things for users.
[Suggested wording]: OAuth2 authentication overhauled. CardDAV address books and CalDAV calendars now use the same OAuth2 code as mail. Provider information is no longer stored in preferences.
[Links (documentation, blog post, etc)]:
Comment 12•24 days ago
|
||
Release note added to 135.0b1. Thanks! I did drop the first sentence to shorten it up to fit on one line.
Updated•23 days ago
|
Description
•