non-oauth2 fastmail calendars no longer authenticating
Categories
(Calendar :: General, defect)
Tracking
(thunderbird_esr128 unaffected, thunderbird134 unaffected, thunderbird135 affected)
| Tracking | Status | |
|---|---|---|
| thunderbird_esr128 | --- | unaffected |
| thunderbird134 | --- | unaffected |
| thunderbird135 | --- | affected |
People
(Reporter: mkmelin, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Tentatively setting as regressed by bug 1927998.
I have a few Fastmail calendars that were set up before they had OAuth2.
First seen with daily 2024-12-04, these calendars can no longer authenticate.
Before setting them up again, I decided to check beta, and with 134.0b1 they (still) work properly in that profile.
Incidentally at the same time I had to re-auth both private gmail and thunderbird.net OAuth2 accounts - hard to say if it was coincidence or not, though I doubt it.
|
Reporter | |
Comment 1•1 months ago
•
|
||
Before this rolls into 135 release, what do we want to do about it?
|
||
Comment 2•1 month ago
•
|
||
It works for me. I have calendars with both old hostname forms caldav-dXXXXXX.fastmail.com, dXXXXXX.caldav.fastmail.com and the current hostname caldav.fastmail.com and they all work.
Calendar discovery does insist on OAuth login if you don't enter the URL, but if you enter the URL from the website or just "fastmail.com" it works fine.
|
|
||
Comment 3•1 month ago
|
||
Actually the OAuth window is a Google one because our work addresses are Google ones. So ignore that.
|
|
Reporter | |
Comment 4•5 days ago
|
||
I'm not sure what's going on here.
I tried to reproduce setting up a calendar with apppasword in 128. That profile works.
In the affected profile, I don't see any (relevant) passwords saved for fastmail, just oauth ones. Maybe the process removed the others.
Description
•