1763564 - OAuth fails using 91.8.0

Status: RESOLVED INVALID

(Thunderbird :: Mail Window Front End, defect)

Description

[Jan-Peter Rühmann]

Attachment: FPpVSiYX0AEG58q.jpeg

User Agent: Mozilla/5.0 (X11; Linux i686; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

Update Thunderbird Via Help Menue to 91.8.0

Actual results:

Thunderbird Shows The Google 0Auth Login every time it tries to get Mail.
But it won´t work.

Expected results:

Get Mail

Comment 1

[Wayne Mery (:wsmwk)]

Do you have cookies disabled?
See https://support.mozilla.org/en-US/kb/automatic-conversion-google-mail-accounts-oauth20

Comment 2

[Jan-Peter Rühmann]

Thanks, Tried it out but no change.
safe Mode don´t change anything to.

Comment 3

[Jan-Peter Rühmann]

BTW this error appears for all Google functions in thunderbird since at least 89. But eMail wurked until now.
Callendar works via the AddOn.

Comment 4

[Wayne Mery (:wsmwk)]

To clarify, you did have cookies disabled?
What exactly is the change you tried?
What do you see for the account in Settings > Privacy > Saved Passwords ?

Comment 5

[Jan-Peter Rühmann]

YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
https://support.mozilla.org/en-US/kb/automatic-conversion-google-mail-accounts-oauth20

https://google.com (Google APIs)
imap://imap.gmail.com (imap://imap.gmail.com)
oauth:[e-mail] (Google Calendar OAuth Token)
smtp://smtp.gmail.com (smtp://smtp.gmail.com)

[e-mail]

Korrekt Password

Comment 6

[Jan-Peter Rühmann]

All Cookies are enabled!
Sorry.

Comment 7

[Jan-Peter Rühmann]

"sudo service apache2 stop" had solved the problem.
Thanks.

Comment 8

[Matt]

Google translate offers that the error is a secure connection failed.

Enter credentials for [e-mail] on imap.gmail.com - 0 X https://localhost/? WATUITA
op=https%3A%2F%2Fmail.google.
Secure connection failed
• This could be a problem with the configuration of the server or
someone pretending to be the server. • If you have previously successfully connected to the server, this may be a temporary error. In this case, try again later.
Or you can add an exception...

So of course we come to the standard culprits.
If you are using a VPN, disable it and try again.
Any other software that is running that utilised the local ghost is suspect as it will be interfering, especially anything like web server software

Comment 9

[Jan-Peter Rühmann]

I disabled all VPNs.
Stoping the Apache Server had solved the problem..

Comment 10

[Matt]

Magnus, this is not the first time I have seen issues with localhost and oAuth. Is there anything we could do code wise to pass the flow to something other than localhost, which can have lots of software monitoring it and intercepting HTTPS traffic, not just Apache? I am not hopeful, but am asking anyway as it does appear to be a weakness.

Comment 11

[Magnus Melin [:mkmelin]]

We can't use anything other than localhost, but we may be able to warn the user. Let's explore that in bug 1748416.