1880646 - Account setup triggers OAuth dialog when looking for calendars after successful creation

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect, P1)

Description

[Alessandro Castellani [:aleca]]

Steps to reproduce:

• Add a new account to Thunderbird, one that doesn't use OAuth but a simple app password
  • If you have access to our shared 1Password account you can use the Test IMAP account from Fastmail.
• Complete the setup.

Result:

• The account is created but upon reaching the final screen an OAuth dialog is prompted when trying to fetch calendars via CalDav.

This shouldn't happen since the test account I'm using doesn't have OAuth enabled and only uses a regular password to connect.

Magnus, would you be able to take a look at this?

Comment 1

[Magnus Melin [:mkmelin]]

I'm not sure what the expectation is, but the result you got doesn't seem wrong - what auth method was used for the email account doesn't have an impact on what calendar/addressbook use for authentication. Actual creds, and servers, can also be different for each.

We always use OAuth2 for fastmail and google calendars.
https://searchfox.org/comm-central/rev/803933402d765dead8a156192127c3197ee4ade0/calendar/providers/caldav/modules/CalDavSession.jsm#377

Comment 2

[Alessandro Castellani [:aleca]]

Thanks for the explanation.
It could be just a case of "user confusion", because as I user if I set my account to only use a plan password and no OAuth, the expectation would be to be able to get calendars without OAuth and by simply authenticating with the same plane password.

I remember it used to be this way in the past, as setting up our old Fastmail accounts was automatically discovering calendars without popping up an OAuth dialog.

Comment 3

[Magnus Melin [:mkmelin]]

Yeah Fastmail OAuth2 for calendars is pretty new. (bug 1785240)

Comment 4

[Alessandro Castellani [:aleca]]

I see.
So is it correct to always and only pass through OAuth for CalDav even if the user specifically set plain password in their Fastmail settings?

Comment 5

[Magnus Melin [:mkmelin]]

I'll have to look at this in more detail.

Comment 6

[Alessandro Castellani [:aleca]]

Increasing the priority of this as it should be fixed before next ESR.
Severity is 2 since this only fails during the first account setup flow, but it's possible to set up calendars via the "New Calendar" dialog independently.

Comment 7

[Magnus Melin [:mkmelin]]

Attachment: Bug 1880646 - Don't fall back to base domain SRV lookup for CalDAV autodiscovery. r=darktrojan

For the thunderbird fastmail imap test account, the issue is that since it's a thunderbird subdomain,
and there are no SRV records for it. During detection we fall back to asking SRV records for the basedomain, which
is thunderbird.net, which is known to be google hosted => we pop up OAuth2 to be able to detect calendars.

We don't fall back to base domain for CardDAV, and I would say we should not do it for CalDAV either.
This would potentially affect someone who is using a subdomain for hosting, but not setting
the SRV records for their subdomain - AND the base domain at the same time are setting the SRV records and
they are usable for the subdomain credentials.
Such cases probably exist, but it would not appear to be a very normal case. Where a subdomain is used
for the email address (which is where we get the subdomain from) likely it's often some kind of testing/staging
environment, like it is for thunderbird.net.

That OAuth2 is requested during account setup during CardDAV/CalDAV autodiscovery is in itself
not unexpected if we discover those services are hosted differently from mail, and thus might
not have the same credentials.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e4ae4563db27
Don't fall back to base domain SRV lookup for CalDAV autodiscovery. r=darktrojan