OAuth2 authentication | 102.7.1. | Linux - fails
Categories
(Thunderbird :: Security, defect)
Tracking
(Not tracked)
People
(Reporter: evan.cooch, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36
Steps to reproduce:
Upgraded TB from 102.6.x on my various Linux boxes to 102.7.1. Attempt to connect to outlook.office365.com, using pop (port 995 - SSL/TLS, and OAuth2 authentication). Works perfectly under TB 102.6.x.
Actual results:
Under 102.7.1, attempts to authenticate quickly collapse into an endless loop. Try to connect. office365 prompts for authentication. I supply, TB then keeps bouncing me back to the same authentication request. Almost exactly the same problem people were reporting with 102.7.0. The point upgrade to 102.7.1 was supposed to have fixed this. Nope -- at least on my Linux boxes. Using Windows in a VM (Win 10 under VirtualBox), 102.7.1 authenticates just fine.
Expected results:
Should have been able to pull mail off pop for outlook.office365.com. Was unable to on my Linux machines.
Updated•2 years ago
|
Comment 1•2 years ago
•
|
||
Sean asked:
-
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.
-
I also ask: Can you login with a new profile/new account, or does that also fail?
I'm still seeing error messages from Microsoft due to an Origin: null header in the oauth request Thunderbird makes.
I have Thunderbird 1:102.7.1-1 on debian testing (with updates done just now). I am trying to set add an office365 account (I may have the wrong terminology there, outlook account?) to thunderbird. But the authentication fails and the account setup cannot be completed.
The request that fails is a POST to https://login.microsoftonline.com/common/oauth2/v2.0/token
It has an Origin: null header in the request.
The response is http 400, with a JSON body:
{"error":"invalid_request","error_description":"AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. Request origin: 'null'.\r\nTrace ID: [uuid recated]\r\nCorrelation ID: [uuid recated]\r\nTimestamp: 2023-02-03 08:22:17Z","error_codes":[9002326],"timestamp":"2023-02-03 08:22:17Z","trace_id":"[uuid recated]","correlation_id":"[uuid recated]","error_uri":"https://login.microsoftonline.com/error?code=9002326"}
If I "Copy as curl" the request, remove the "-H 'Origin: null'", and execute the command, I get a response that looks like a successful authentication.
Closed bug 1810760 claims the Origin null-issue was fixed, but I am not seeing that. Though perhaps I am not interpreting those closing comments correctly.
I tried this both with a new profile, and with my existing profile where I had the same account configured before (I tried deleting and adding it again when authentication started failing).
Closed bug 1810760 claims the Origin null-issue was fixed, but I am not seeing that. Though perhaps I am not interpreting those closing comments correctly.
It looks like I'm getting confused by version numbers, and this is all known and being worked on. Sorry for the noise. For reference, the debian bugreport appears to be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029594
Comment 4•2 years ago
•
|
||
(In reply to mjl from comment #3)
It looks like I'm getting confused by version numbers, and this is all known and being worked on. Sorry for the noise. For reference, the debian bugreport appears to be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029594
The problem is that package maintainers don't understand that they can't just build untested things. We release builds after they've been tested internally, and they never wait for that. So they push out known-broken builds to their users.
The correct, actually released 2nd build of 102.7.1 was not built until Jan 31, and not released until Feb 01. Any builds that originated prior to those dates are almost certainly bad.
(if I sound a little exasperated that's because we've gotten MANY incorrect/misleading reports due to this in the past 2 days :/)
Reporter | ||
Comment 5•2 years ago
|
||
(In reply to Andrei Hajdukewycz [:sancus] from comment #1)
Sean asked:
- 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.
Well, AlmaLinux, which amounts to RHEL. As for the install, dnf install thunderbird from the @appstream repo.
102.7.1-1.el8_7.alma
I haven't tried using the tarball (manually extracting to /etc/lib64/thunderbird, on RHEL-based systems), but I'm happy to try.
- I also ask: Can you login with a new profile/new account, or does that also fail?
Not quite sure what you're suggesting - if you can give me a couple of step-by-steps here, I'll give it a shot.
In the short term, I have 102.6.1 running - and working - on all my Windows and Linux machines, so I'm not at a 'mission critical' stage. But, I never like to get too far behind the release version.
Note: not sure if this is useful data but...if I try upgrading my Windows machines to 102.7.1, the update doesn't work. On the other hand, if I do a new install under Windows (Win 10 in a virtual machine), 102.7.1 works perfectly. Makes me wonder if the issue has to do with in-place updates (which may or may not work) vs clean, new installs (which seems to work based on my VM installs). Same network, same Office365 back-end.
Just a thought...
Reporter | ||
Comment 6•2 years ago
|
||
So, I'm now increasingly convinced that for me (and perhaps a lot of people) that the continuing issues might be a function of in-place upgrades not working 'perfectly'.
Following a question from Andrei Hajdukewycz (comment 1), I tried a manual install on my Linux boxes. I downloaded the latest tarball, and manually extracted all of the contents into /usr/lib64/thunderbird (where TB is installed on RHEL-based distros), overwriting the 102.6.1 files that were there.
Fired up TB, and was prompted to re-authenticate Oauth2, and....it worked!!! Both pulling mail off pop.office365.com, and SMTP out using smtp.office365.com.
I'll need to figure out the best way to do the equivalent 'manual install' on my Windows boxes.
Reporter | ||
Comment 7•2 years ago
|
||
Or -- perhaps the latest tarball is in fact the right tarball, and the version of TB 120.7.1 released by package maintainers to the Almo repos was in fact out of date.
Comment 8•2 years ago
|
||
(In reply to evan.cooch from comment #7)
Or -- perhaps the latest tarball is in fact the right tarball, and the version of TB 120.7.1 released by package maintainers to the Almo repos was in fact out of date.
The tarball on https://www.thunderbird.net is definitely the right one, the Thunderbird website is always the canonical place for the correct build of any version.
Comment 9•2 years ago
|
||
102.7.2 is live, please test and report in this bug if you are still experiencing any issues.
Comment 10•2 years ago
|
||
(In reply to evan.cooch from comment #5)
Well, AlmaLinux, which amounts to RHEL.
102.7.1-1.el8_7.alma
Please wait for the 102.7.1-2 release.
Comment 11•2 years ago
|
||
I am having a similar problem of Fedora 37 Thunderbird build 102.8.0-1.fc37 installed using dnf. Problems started after the upgrade to 102.7. Have deleted .thunderbird directory and started again to no avail.
Comment 12•2 years ago
|
||
Bug 1817735 perhaps? Looks like the fedora packages are a bit broken. Try a binary from thunderbird.net
Comment 13•2 years ago
|
||
I just downloaded 102.8.0 and ran it from extracted directory and had the same problem.
Updated•2 years ago
|
Comment 14•1 year ago
|
||
Evan, has this improved?
Updated•9 months ago
|
Reporter | ||
Comment 15•9 months ago
|
||
It all seems to work now. I skip repo updates, and pull things directly out of the tarball. I'm currently 115.8.0 on all my machines, including RHEL 8.
Description
•