Can't authenticate to Office 365 with oauth

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.102 Safari/537.36

Steps to reproduce:

upgraded the snap package for thunderbird (sudo snap refresh thunderbird) which took thunderbird from revision 281 (102.6.0-2) to revision 288 (102.7.0-1).

Actual results:

After upgrading, it prompted me to re-sign into my organisation's office 365 account, so I entered my password (the username/email address was prefilled in from the previous version I assume), entering my password gave me a new window asking for my OTP code for 2FA, I gave this and then the window closed and a banner on the screen showed saying authentication failure.

Expected results:

After entering the OTP code, it should have logged me in, and allowed me to use email services.

as an aside, I reverted the package to the previous version using sudo snap revert thunderbird --revision 281, and re-signed in again, and this worked.

To rule out my machine being at fault, I spun up a new ubuntu 22.04 desktop vm, and purged the default thunderbird from the system, and did a fresh snap install of thunderbird which automatically put on the latest revision 288 / 102.7.0-1. I was also unable to log into my office 365 account using 102.7.0-1.

From the Azure side our administrator saw this;

Sign-in error code
9002326
Failure reason
Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. Request origin: '{origin}'.
Additional Details
The application must fix either the reply URIs registered on the application registration to include a unique reply address of type "spa", or they must fix the token request to not include an Origin header, if being sent from a non-browser client.

Sean will take a look at this. Hopefully a fairly straightforward fix. Thanks for the report, especially the admin side log.

Seconding Andrei's thanks for the admin log.

Could you try the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2 and see if that fixes the issue?

I ran into exactly the same issue as described above when updating the Thunderbird snap from revision 281 (102.6.0-2) to revision 288 (102.7.0-1) and came across this report when trying to troubleshoot. I can confirm that when using the build linked in the comment above, the Oauth2 authentication works correctly.

Same issue here, using mozillateam ppa on Ubuntu.

(In reply to Sean Burke [:leftmostcat] from comment #4)
> Seconding Andrei's thanks for the admin log.
>
> Could you try the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2 and see if that fixes the issue?

Yes this seems to work fine standalone, I extracted it and ran thunderbird-bin and after re-setting up my office365 mail account it did connect and allow me to get to my email.

Thanks for the quick help!

*** Bug 1811013 has been marked as a duplicate of this bug. ***

I have the same problem since upgrading from 102.4.2 to 102.7.0. I can confirm that when using the build above OAuth2 authentication works for both outgoing and incoming email.

*** Bug 1811279 has been marked as a duplicate of this bug. ***

Users of version 102 will want to be using [**102.6.1**](http://ftp.mozilla.org/pub/thunderbird/releases/102.6.1/) until probably 102.7.1.
Someone on Kubuntu 22.04 wrote this worked well:
`sudo apt-get install thunderbird=1:102.4.2+build2-0ubuntu0.22.04.1`

Users of nightly (daily) builds will want to use the build artifacts of [Sean's try build](https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=3f93137249556d2e228e02db437d812f8a7d0a34), until at least a day or two after this bug is marked fixed
* [linux](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2)
* [Windows](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/R6SjuwMOSrOxLRuQOadGCQ/runs/0/artifacts/public/build/install/sea/target.installer.exe)
* [Mac](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/KC-mgcR4SX6gMYkaB7SW3A/runs/0/artifacts/public/build/target.dmg)

(In reply to Sean Burke [:leftmostcat] from comment #4)
> Could you try the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2 and see if that fixes the issue?

Hey Sean, can you attach your patch here, please?

(Thanks christian for the admin log. Very helpful. And thanks to the MS devs who gave a helpful error message.)

In response to bug 1811279 (see further details there) and this one, I'm still using Ubuntu 20.04LTS , reverted TB back to previous version and then did:
```
sudo apt-mark hold thunderbird
```
... in order to temporary hold this version.

For ubuntu snap users that received an automatic update to version 102.7.0, the following commands will revert to the previous version and temporarily hold updates for one week until the new version is (presumably) released. Make sure you quit any running instance of Thunderbird before executing the commands. Note that the 'hold' option requires snapd v2.58 or higher.

```
snap revert thunderbird
snap refresh --hold=168h thunderbird
```

If a fixed version is released before this time the hold can be lifted by executing:

```
snap refresh --unhold thunderbird
```

Created attachment 9313356
Bug 1810760 - don't use CORS with client requests. r=#thunderbird-reviewers

Comment on attachment 9313356
Bug 1810760 - don't use CORS with client requests. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): 1685414
User impact if declined: Microsoft oAuth account users will not be able to authenticate.
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): Although the code changes are isolated to Microsoft accounts, it's possible we break some other oAuth flow. Testing should mitigate this risk. I have personally tested with gmail in addition to outlook.com and it seems fine.

Pushed by <email address hidden>:
https://hg.mozilla.org/comm-central/rev/638f3a309f8c
don't use CORS with client requests. r=sancus

*** Bug 1811752 has been marked as a duplicate of this bug. ***

Comment on attachment 9313356
Bug 1810760 - don't use CORS with client requests. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Approved for er102, pending beta release, per Chat with sancus

wsmwk: I think we should push it through. Like build and ship beta on Monday and build 102.7.1 on Monday to ship Tuesday or Wednesday
sancus: OK sounds good

Thunderbird 110.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/00ca8e3c8d58

*** Bug 1811966 has been marked as a duplicate of this bug. ***

Thunderbird 102.7.1:
https://hg.mozilla.org/releases/comm-esr102/rev/88d80acadbab

*** Bug 1812000 has been marked as a duplicate of this bug. ***

*** Bug 1811998 has been marked as a duplicate of this bug. ***

Based on the report in bug 1812090 the final fix for this bug didn't work.

What happened here is that the patch does not seem to work properly on 102 branch. The "Origin: null" header remains. Daily and 110b2 are both working in my testing.

*** Bug 1812090 has been marked as a duplicate of this bug. ***

*** Bug 1812077 has been marked as a duplicate of this bug. ***

(In reply to Andrei Hajdukewycz [:sancus] from comment #26)
> What happened here is that the patch does not seem to work properly on 102 branch. The "Origin: null" header remains.

Bug 1605305 fixed this, particularly: https://hg.mozilla.org/mozilla-central/rev/28cf8d7e9723#l2.13, also see commit message:
This patch [...] prefers to send **no Origin header instead of Origin: null.**

Just a drive-by thought, without having dug into this problem:

The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs.

Adalbert's comment 29 suggests one specific code block to be related.

You could test a build that removes this one block (red) from mozilla-esr102. Maybe that code block could be slightly improved to keep the header if the origin is non-null. (In other words, only suppress if origin is null).

If that indeed works without other regressions for Thunderbird, you could ask for that change on mozilla-esr102 with ```#ifdef MOZ_THUNDERBIRD```

(In reply to Kai Engert (:KaiE:) from comment #30)
> Just a drive-by thought, without having dug into this problem:
>
> The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs.
>
Yes, I don't think uplifting that one is going to happen.
> Adalbert's comment 29 suggests one specific code block to be related.

Yeah, Sean and I found that code earlier. We could patch only that block ourselves the way you suggested or by applying a patch during the build process. A JS workaround would be preferred, however, so we're still investigating that.

(In reply to Kai Engert (:KaiE:) from comment #30)
> Adalbert's comment 29 suggests one specific code block to be related.

That's a misunderstanding. That block likely creates the `Origin: null` header for the "POST" that is run in the fetch() in OAuth2.jsm. However, the functionality of this hunk is added elsewhere. IOW, if you only remove this code without taking the other hunks of the patch, no Origin header will ever be sent, even in situations where it's needed.

In earlier versions of TB ESR there was a branch on the Mozilla ESR repo for uplifting patches that TB needed but FF didn't want to uplift. Looks like this practice was abandoned from TB 91. BTW, the regressions don't look relevant to TB.

Thanks for your helpful clarification!

It does seem likely that we can use a different method in JS rather than trying to patch the fetch code so Sean is currently working on that.

Created attachment 9314399
Bug 1810760 - use HTTP channels instead of fetch for oauth token. r=darktrojan

Created attachment 9314407
Bug 1810760 - use HTTP channels for Microsoft oauth. r=darktrojan

@hotmail.com still not working.

110.0b3 (64-bit) Windows

windows

I can confirm that with the recent Thunderbird 102.7.1-2 build in the latest/candidate snap channel I can both receive (imap) and send (smtp) emails on a Microsoft O365 account with OAuth2. Other OAuth accounts such as google are also working.

(In reply to Andrey Kiryanov from comment #66)
> Hi,
>
> I can confirm that after installing the 102.7.1 (64-bit windows) I can now READ e-mails from office365 account, but I still cannot SEND them.
> SMTP auth window pops up, everything goes as normal, except that after a couple of seconds TB shows "Login to server outlook.office365.com failed". I've tried deleting OAuth tokens from the password manager and re-authenticating but to no avail.

Here's what I see in the error console:

ailnews.smtp: Command failed: 535 Authentication unsuccessful [GVYP280CA0032.SWEP280.PROD.OUTLOOK.COM 2023-02-01T13:00:01.837Z 08DB04378CB01E1D]; currentAction=_actionAUTH_XOAUTH2 SmtpClient.jsm:515:19
    _onCommand resource:///modules/SmtpClient.jsm:515
    _parse resource:///modules/SmtpClient.jsm:360
    _onData resource:///modules/SmtpClient.jsm:414
mailnews.smtp: Error during AUTH XOAUTH2, sending empty response

IMAP authentication with the very same credentials works though.

TB 102.7.1 as posted to servers does not correct this issue for me (Linux x86-64). After reverting to 102.6.0 , works fine again.

Update:

I tried the tarball listed above:

This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

This worked properly to send and receive emails from my corporate office365 account. Need to pass the --ProfileManager option to the manual start to ensure that I could select an existing profile.

Hi everybody !
Sorry for my poor english but I want to share a thing with you !

On Arch Linux, i installed TB 109.0b4 and I can send I receive mail from office server.

But, in same time , and I don't know is it possible ! but the same account on TB 102.7.0 (64 bits) that was bad are NOW useful !

I have not the explaination but I want to write this to you !

Why ? somebody could say ?

Thanks

Turns out SMTP will be a different bug. Will post a bug# soon.

<dang, wising one could edit their own post>
official TB 102.7.1 does NOT correct the Office365 issue w/ IMAP (receive mail is still broken). I cannot get far enough to test SMTP 'mail-send'. Both send/receive mail work just fine after downgrade to TB 102.6.0 though.

Because of the inconvenience this issue causes users, 102.7.1 should be retracted until both IMAP and SMTP issues are resolved and *much* positive testing-feedback has been received.

 Just a suggestion- could a config/registry setting be added to TB to disable this recent feature-addition? It would be much easier to instruct users to simply disable this feature than to force them to uninstall/downgrade/reinstall the entire program to restore their email capability.

(In reply to Ron Flory from comment #75)
> <dang, wising one could edit their own post>
> official TB 102.7.1 does NOT correct the Office365 issue w/ IMAP (receive mail is still broken). I cannot get far enough to test SMTP 'mail-send'. Both send/receive mail work just fine after downgrade to TB 102.6.0 though.

I can't reproduce any issues signing into Office365. Do you experience this problem with a new profile or only an old profile? There are some problems with old oAuth settings being retained which we may still need to resolve.

We could revert, yes, but this will only kick the can down the road, because 115 will still be changed. It's not possible for oAuth to continue working the way it does in 102.6.1 and prior.

> Because of the inconvenience this issue causes users, 102.7.1 should be retracted until both IMAP and SMTP issues are resolved and *much* positive testing-feedback has been received.

The testing you're suggesting isn't actually possible. We did have these changes on nightly/beta for some time, and didn't have any problems reported. 102 is its own branch and in addition there is an absolutely absurd amount of variation in Microsoft policies and technical setups, far more than is represented in the beta population.

The reality is, Microsoft REALLY does not want this to work easily.

If you're having problems with *only* SMTP, please see [bug 1775077#c10](https://bugzilla.mozilla.org/show_bug.cgi?id=1775077#c10) and follow the instructions in the comment.

Problem persists for my Linux machines (RHEL), after upgrading to 102.7.1. My Windows machines don't seem to have a problem, but 3/3 Linux machines - nope. And, I'm using pop, not imap.

This is still not working on my Mac or my family member's Mac. When trying to configure for POP3, I get a message that says "You are about to override how Thunderbird identifies this site." The location is set to "outlook.office365.com:995" and it asks me to get a certificate, the certificate lists "outlook.office365.com" but without any ports.

When I try the "Get Certificate" button, it replies "This site attempts to identify itself with invalid information. When I remove the port 995, so the location says "outlook.office365.com" and press the "Get Certificate" button it replies "Valid Certificate, this site provides valid, verified identification. There is no need to add an exception." Except that this point there is only a Cancel button.

If I leave in the port so the location says "outlook.office365.com:995" and press the "Confirm Security Exception" button, it replies "Unknown Identity. the certificate is not trusted because it hasn't been verified as issued by a trusted authority using a secure signature".

And the checkbox on the is unchecked as mentioned in bug 1775077#c10 on the Admin Exchange panel.

(In reply to steve from comment #79)
> This is still not working on my Mac or my family member's Mac. When trying to configure for POP3, I get a message that says "You are about to override how Thunderbird identifies this site." The location is set to "outlook.office365.com:995" and it asks me to get a certificate, the certificate lists "outlook.office365.com" but without any ports.

Haven't a clue what's going on here, and can't reproduce any of this. Not even sure how it could be related to this bug. So you're saying:

1) This worked before 102.7.0 ?
2) Does this work if you make a new profile and login on 102.7.1?
3) If the answer to #2 is "no" does it work on 110 beta?

Thanks.

It worked for 19 years on my own POP3 server, then 10 years on outlook hosted on Rackspace, then after the Rackspace meltdown in November, Thunderbird worked for about 2 months on outlook.office.365.com. Then on about January 23rd, (we had not yet upgraded to 102.7.0), both my Thunderbird and my Wife's started looping on asking for the password over and over again. I tried many different things (ports, protocols, etc.) and never got a download again, the IT guy at my corporate account said that he could see me signing in, but I never got a download. We can get our mail with Mac Mail and iOS Mail, but those are IMAP. I have a couple of decades of thunderbird emails that I would like access to again (I really want to get thunderbird going again).

I lost all my profiles, in the "trying things" stage, so yes, I created a new profile on 102.7.1 and used both autodetect, and ports and protocols experiments. Still looping.

I just downloaded Thunderbird 110.0b3.pkg, I'll give it a try.

 110.0b3.pkg creates a executable called "Thunderbird Daily.app". Starting it up takes you to the Startup screen, where the same problem occurred. I think it said "You are about to override how Daily identifies this site."

So I went to the About page, and there was a button that said "Restart to update" and after the restart the About pane said "111.0a1 (2023-02-01) (64-bit)" This time it did take my password, but maybe did not redirect to the Microsoft OATH page, but signed me in. It does not however download new messages.

The contents of the error log:

```
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
1675313850290 addons.xpi WARN Checking /Applications/Thunderbird Daily.app/Contents/Resources/distribution/extensions for addons
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
```
```
TypeError: can't access property "parentNode", mainKeyset is null
DevToolsStartup.sys.mjs:696:5
Found 0 public keys and 0 secret keys (0 protected, 0 unprotected) RNPLib.jsm:546:15
services.settings: Failed to load last_modified.json: TypeError: NetworkError when attempting to fetch resource. Utils.jsm:330
1675313851206 places TRACE FrecencyRecalculator :: Initializing Frecency Recalculator
1675313851206 places TRACE FrecencyRecalculator :: Start frecency recalculator interval check
1675313851207 places TRACE FrecencyRecalculator :: Got places-init-complete topic
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
1675313851403 Sync.Status INFO Resetting Status.
1675313851407 Sync.Service INFO Loading Weave 1.113.0
Trying to load /Applications/Thunderbird Daily.app/Contents/MacOS/libotr.dylib OTRLib.sys.mjs:64:11
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
Successfully loaded OTR library /Applications/Thunderbird Daily.app/Contents/MacOS/libotr.dylib OTRLib.sys.mjs:72:13
1675313851534 Sync.Service INFO Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0 Thunderbird/111.0a1
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITelemetry...

Well the pasting is not going well, so here is the log in a google doc
https://docs.google.com/document/d/1W0v1b8joDAQlZBCX9qu6D0SgpDRByUJFkAkmi8GZeyY/edit?usp=sharing

(In reply to steve from comment #83)
> 110.0b3.pkg creates a executable called "Thunderbird Daily.app". Starting it up takes you to the Startup screen, where the same problem occurred. I think it said "You are about to override how Daily identifies this site."
> I'll paste the rest in the next comment (Bugzilla problems with large pastings)

I don't think you're experiencing anything related to this bug at all, sorry. If you had problems before upgrading to 102.7.0 it's not possible.

Also, there is nothing wrong with the office365.com SSL certificate, the fact that you're seeing these certificate issues implies you have some sort of antivirus installed that MITMs certificates or something like that, [as described in this support request](https://support.mozilla.org/en-US/questions/1311167).

You should never, ever have to do a certificate override on a mail server and it's not related to oAuth.

Then I restarted Thunderbird (110.0b3 (64-bit)) and tried it again, and got the MS OAUTH pop up which was good progress, and signed in, then on the Thunderbird Account Setup page "Account successfully created" was displayed also good progress.

Now it is downloading 293 of 5444 emails -- a good start! I get a lot of emails, and have lots of Thunderbird filters to deal with them. I'll have to see in the morning if it completed.

I'll look into antivirus issues in the morning. Thanks

(In reply to Fabian Dellwing from comment #65)
> (In reply to Wayne Mery (:wsmwk) from comment #60)
> > build 2 of 102.7.1 is now shipped.
> >
> > Thank you all for your patience and testing results. This gives us more confidence in what we are shipping.
>
> When will it hit the mozillateam PPA?

Still not available on the PPA

Good morning,

It seems that with 102.7.1, the synchronisation works excepted the calendar. No calendar sync with O365. Anyone has an idea?

Thank you in advance.

Regards.

David

(In reply to David F from comment #88)
> Good morning,
>
> It seems that with 102.7.1, the synchronisation works excepted the calendar. No calendar sync with O365. Anyone has an idea?
>
> Thank you in advance.
>
> Regards.
>
> David

You always needed a 3rd party addon (mostlikly TbSync+EAS) to get calendar access?

(In reply to Fabian Dellwing from comment #89)
> (In reply to David F from comment #88)
> > Good morning,
> >
> > It seems that with 102.7.1, the synchronisation works excepted the calendar. No calendar sync with O365. Anyone has an idea?
> >
> > Thank you in advance.
> >
> > Regards.
> >
> > David
>
> You always needed a 3rd party addon (mostlikly TbSync+EAS) to get calendar access?

The problem with TBSync +EAS, you will not see the details of the meeting and with Owl, you will see the meeting details but if you postpone or modify the meeting, the changes will not be synchronized.

Hello, having issues with connection to Office365 Calendar since 102.7.0 (using EAS + TBSync).

I installed 102.7.1 and the issue persists, even deleted the account and recreating it...

It seems a browser window is directed to the following url after input of EAS account details for creation (Office 365 account type) and it's failing.

https://undefined/?response_type=code&client_id=undefined&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient&scope=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize&login_hint=<accountusername>%40<accountdomain>

Note: <accountusername> and <accountdomain> had actual data, hidden for privacy.

I tried with 102.7.1 under Linux and the problem occurred there. TB 102-.76.1 is working fine.

(In reply to Lars Hennig from comment #92)
> I tried with 102.7.1 under Linux and the problem occurred there. TB 102-.76.1 is working fine.

But not with the calendar...

(In reply to Lars Hennig from comment #92)
Need to correct the version working for me: TB 102.6.1 is working fine for IMAP.
Calendar never worked for me as IT does not allow to access the calendar through Thunderbird.

Testing with Ubuntu 22.04.1:

**102.7.1+build1.2-0ubuntu0.22.04.1~mt1** from the PPA does **not** fix the problem for me, login is still not possible.
However, the standalone download version ([thunderbird-102.7.1.tar.bz2](https://download.mozilla.org/?product=thunderbird-102.7.1-SSL&os=linux64&lang=en-US)) works fine: login, sending, receiving mails works again.

> **102.7.1+build1.2-0ubuntu0.22.04.1~mt1** from the PPA does **not** fix the problem for me, login is still not possible.
> However, the standalone download version ([thunderbird-102.7.1.tar.bz2](https://download.mozilla.org/?product=thunderbird-102.7.1-SSL&os=linux64&lang=en-US)) works fine: login, sending, receiving mails works again.

Update: **102.7.1+build2-0ubuntu0.22.04.1** was just released on the Mozilla Team PPA and this build **fixes the problem** for me. Thanks!

There is a problem with upgrading to 102.7.1+build2-0ubuntu0.22.04.1.

1. Currently running 1:102.4.2+build2-0ubuntu0.22.04.1 from mozillateam PPA
2. Close TB and upgrade to 102.7.1+build2-0ubuntu0.22.04.1 from mozillateam PPA
3. Backup my profile folder
3. Run TB
4. Can't authenticate. My university's OAuth popup just says "Stale request". Nothing can do will let me reauthenticate.
5. Close TB and create a test profile.
6. Works
7. Close TB and Downgrade to 1:102.4.2+build2-0ubuntu0.22.04.1
8. Run TB using original profile
9 Same problem as above
10 Close TB and try test profile.
11. Works
12. Restore original profile from backup
13. Run TB. Works.

Running a diff between the backup profile and the broken one shows a lot of changes in lots of files.

I worked with the broken profile and found that by deleting logins.json from the profile I was able to get it working again.

(In reply to emeitner from comment #97)
> There is a problem with upgrading to 102.7.1+build2-0ubuntu0.22.04.1.
>
> 1. Currently running 1:102.4.2+build2-0ubuntu0.22.04.1 from mozillateam PPA
> 2. Close TB and upgrade to 102.7.1+build2-0ubuntu0.22.04.1 from mozillateam PPA
> 3. Backup my profile folder
> 3. Run TB
> 4. Can't authenticate. My university's OAuth popup just says "Stale request". Nothing can do will let me reauthenticate.
> 5. Close TB and create a test profile.
> 6. Works
> 7. Close TB and Downgrade to 1:102.4.2+build2-0ubuntu0.22.04.1
> 8. Run TB using original profile
> 9 Same problem as above
> 10 Close TB and try test profile.
> 11. Works
> 12. Restore original profile from backup
> 13. Run TB. Works.
>
> Running a diff between the backup profile and the broken one shows a lot of changes in lots of files.
>
> I worked with the broken profile and found that by deleting logins.json from the profile I was able to get it working again.

Did you try to remove any auth information from your university's mail server (e.g. "oauth://" entries) from the stored credentials in Thunderbird? I can force a reauth by doing that.

Thunderbird does not support O365 calendars in the first place, so please don't post in this bug if you're having a calendar problem. If you have a problem with an add-on, report that to the add-on author -- not here, where we can't do anything about it.

Bugzilla is also NOT a place for tech support.

(In reply to cr0n from comment #95)
> Testing with Ubuntu 22.04.1:
>
> **102.7.1+build1.2-0ubuntu0.22.04.1~mt1** from the PPA does **not** fix the problem for me, login is still not possible.

Ubuntu PPA is not a build from Mozilla, and it seems they pushed a broken build of 102.7.1 that we never released. For anyone else on the PPA, make sure you are on the NEWEST 102.7.1 PPA build - **build 2**. Yes, there's two. Yes it's dumb.

(In reply to Andrei Hajdukewycz [:sancus] from comment #99)
> Thunderbird does not support O365 calendars in the first place, so please don't post in this bug if you're having a calendar problem. If you have a problem with an add-on, report that to the add-on author -- not here, where we can't do anything about it.
>
> Bugzilla is also NOT a place for tech support.

Sorry, no.

TBSync + EAS worked - with their own known limitations - perfectly before 102.7.0.
This Thunderbird version broke everything and the extensions did not change. So it's definitely Thunderbird (102.7) fault, especially because no changes in plugin compatibility were announced.

And this is a place about Thunderbird issues, right?

Thanks,
   Mario

(In reply to evan.cooch from comment #78)
> Problem persists for my Linux machines (RHEL), after upgrading to 102.7.1. My Windows machines don't seem to have a problem, but 3/3 Linux machines - nope. And, I'm using pop, not imap.

What method do you use for installing on RHEL? I've attempted to reproduce by downloading the Linux tarball, running that version, and adding a Microsoft enterprise account using POP with OAuth, but I was unable to reproduce any issue.

The original bug(data in Origin header) has been fixed, so I'm going to close this, as it's gotten unwieldy. We do have other regressions and new bugs caused by Microsoft, so if you are experiencing any of the following you can comment... **WITH DETAILED STEPS TO REPRODUCE, PLEASE**:

**ON LINUX**, can login on 102.6.1, cannot on 102.7.1: Bug 1814536
Can login to IMAP/POP3 but **NOT SMTP** with OAuth: Bug 1775077 (note a workaround is to use basic authentication eg user/pass for SMTP only)
**On 102.7.1**, have certificate error messages with OAuth: Bug 1814824
**Profiles created prior to 102.7.1 cannot login**, but new profiles CAN: Bug 1814823

If you're experiencing something that doesn't fall into any of these categories, please check the [Microsoft OAuth Meta Bug](https://bugzil.la/1814820) and if your problem is not represented there, file a new bug. Calendar issues should be reported to the respective add-on, Thunderbird does not support Exchange calendars.

Unfortunately, these changes were required by Microsoft policy and technical changes to their OAuth system, and while reverting to 102.6.1 may temporarily solve some problems, the authentication on 102.6.1 is broken and has [other bugs](1685414) in it.

Thank you for bearing with us. We're equally frustrated with these problems and we will fix them.

Also, if you are **on Linux** and think you are still experiencing this specific bug(Origin: null in the header), make sure you are using 102.7.1 as it was released on https://www.thunderbird.net.

Multiple package maintainers built an untested, unreleased build of 102.7.1. If a 102.7.1 build originated prior to Jan 31, 2023, then it is probably a bad build and you need to update again.

*** Bug 1811460 has been marked as a duplicate of this bug. ***

Comment on attachment 9314698
1810760-tidy-trunk.patch

Review of attachment 9314698:
-----------------------------------------------------------------

The revision in question has been backed out of the tree, patch is no longer needed.