[SRU] Authentication constantly re-requested for Google

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Clean install Thunderbird 68.2
- Add Gmail account
- Fill in Google Authentication popup window and allow app
- Fails at next window

Actual results:

Email is not synced at all

Warning saying:
Unable to log in at server. Probably wrong configuration, username or password

Password & username is correct

Expected results:

Login should Continue and account should start syncing email

Tried older versions and latest Thunderbird beta 71 with the same results
Maybe Google has changed something with their OAuth2 requirements ?

Also should note the email is not auto-filled in the Google login popup (this used to be auto-filled)

Created attachment 9105051
Log from login process

I test creating my Google IMAP account and Comcast POP3 account with every release candidate. I had no problem creating the accounts when testing the 68.2 candidate on Ubuntu 18.04.2 LTS. I still have that test profile and I can get mail on the account.

After seeing this bug report in my Gmail Bugzilla folder, I tested my 68.2 with a test profile on both Windows 10 and Ubuntu, and can reproduce the problem.

I just tested creating the account with a new test profile using 71.0b1 on Ubuntu 18.04.3 LTS and can reproduce.

I don't recall seeing the dialogs from Google that appear now when testing release candidates.

No changes in that area between TB 70 beta 4 and TB 71 beta 1. Does it still work with TB 68?

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

Sorry, you said 68.2.0. Hmm, looks like Google finally tightened the screw. Magnus and Andrei, do you know anything about this?

Created attachment 9105072
gmailerrorlog.txt

Creating an account in 68.2 with a test profile. No.

The user would normally get a dialog window with the email address already filled in and all they had to do was click "Next" to get to the dialog window to enter the password. Now I have to fill in my email or phone number.
Entering the email address and clicking next brings up the window to fill in the password, showing my email address and avatar associated with the account.
Typing in the password and clicking next brings up the "Mozilla Thunderbird Email wants to access your Google Account" dialog window.
Clicking the "Allow" button is where it fails.

No problem using my account in 68.2 or 70.0b1 or 72.0a1 with the production profiles on Windows 10 or Linux.

I've just confirmed it. After answering all the Google prompts incl. tying in a code received via SMS, the authentication fails :-( - An existing account still seems to work.

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

Yeah, I can't get gmail to auth either. The google oauth stuff looks the same to me, we still have the same authorizations we had before. There weren't any messages from Google either.

The only thing I can think of is that there is apparently a token rate limit, but it's not clear to me what that applies to, and there's no data for how many tokens we're granting per day, so I have no idea if it's even working right.

After setting mail.wizard.logging.dump to 'all' and mail.wizard.logging.console to 'all', when Thunderbird makes a request to https://www.googleapis.com/oauth2/v3/token the response is '400 bad request' with {"error": "invalid_grant", "error_description": "Malformed auth code."}

https://blog.timekit.io/google-oauth-invalid-grant-nightmare-and-how-to-fix-it-9f4efaf1da35

Googling makes it sound like it's a generic error that can apply to any number of scenarios. So I don't know. Maybe Fallen has some idea what could be going on here? Do we have Google contacts we can ask about this?

As of this moment, gmail auth is broken for all users and the error message may as well be 'something is wrong'.

I just came across this on the mozillaZine forum where the poster indicates using "normal password authentication" works.

http://forums.mozillazine.org/viewtopic.php?p=14848558#p14848558

Yes, you can set an app password using the "less secure apps" option in Google as a workaround. That won't fix the oauth bug itself, of course.

I can confirm the bug, at least in 60 (i'm switching to 68 now...), 32bit, Win7.

Trouble happen if users change their password, and (i suppose) more generally on token change. If token is valid, all works as expected.

Obviously 'normal password' works if enabled on google site.

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

Looking at the docs at https://developers.google.com/identity/protocols/OAuth2InstalledApp we should probably update the urls as so.
```
 - "https://accounts.google.com/o/oauth2/auth",
 - "https://www.googleapis.com/oauth2/v3/token",
 + "https://accounts.google.com/o/oauth2/v2/auth",
 + "https://oauth2.googleapis.com/token",
```

Unfortunately, that doesn't help any :(

These are the relevant network requests. For the AccountChooser for whatever reason we end with a param to get sent to the legacy auth (https://accounts.google.com/signin/oauth/legacy/consent). I'd imagine that's the root of the problem.

curl 'https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost&scope=https%3A%2F%2Fmail.google.com%2F&login_hint=example%40gmail.com' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Thunderbird/72.0a1' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1'

curl 'https://accounts.google.com/signin/oauth?client_id=406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com&as=raOi9ApwBeyZIud8WPVzhg&<email address hidden>&destination=http://localhost&approval_state=!ChR2ZTJFaTBWQ2ZtMzhvMEVFOXhySxIfMDFiWFlJVWhNejhhOERFdWhZOThQY18xSm8zSDRSWQ%E2%88%99AJDr988AAAAAXbrIfhVE7FpoqoGhuBlX2DvLqjmU3VA6&oauthriskyscope=1&xsrfsig=ChkAeAh8T_oe9FxRgZIFTl3qVXN0iKZcn16rEg5hcHByb3ZhbF9zdGF0ZRILZGVzdGluYXRpb24SBXNvYWN1Eg9vYXV0aHJpc2t5c2NvcGU' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Thunderbird/72.0a1' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Referer: https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost&scope=https%3A%2F%2Fmail.google.com%2F&login_hint=example%40gmail.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: OCAK=fwSdeZHWp9M0a0jvnbwWEu57NPSzYGYQXIyvq3awhbw' -H 'Upgrade-Insecure-Requests: 1' -H 'TE: Trailers'

curl 'https://accounts.google.com/signin/oauth?client_id=406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com&as=raOi9ApwBeyZIud8WPVzhg&<email address hidden>&destination=http://localhost&approval_state=!ChR2ZTJFaTBWQ2ZtMzhvMEVFOXhySxIfMDFiWFlJVWhNejhhOERFdWhZOThQY18xSm8zSDRSWQ%E2%88%99AJDr988AAAAAXbrIfhVE7FpoqoGhuBlX2DvLqjmU3VA6&oauthriskyscope=1&xsrfsig=ChkAeAh8T_oe9FxRgZIFTl3qVXN0iKZcn16rEg5hcHByb3ZhbF9zdGF0ZRILZGVzdGluYXRpb24SBXNvYWN1Eg9vYXV0aHJpc2t5c2NvcGU' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Thunderbird/72.0a1' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Referer: https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com&redirect_uri=http%...

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

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

For the authentication step, override the useragent and change it to Firefox.

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

As per comment #20 and https://github.com/kewisch/gdata-provider/issues/26#issuecomment-547994463, setting general.useragent.compatMode.firefox to true allows IMAP access again. Not tested for gData, but no reason to distrust the GitHub post.

I tested the workaround with gData for Calendar and it worked as expected.

I confirm too, workaround work!
(tested win32 60.9.0 version)

Created attachment 9105309
1592407-github-fix.patch

As far as I can tell, this works. I claim no merit, all I did was copy/paste.

Jorg, would Bug 1592342 depends on this bug?

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

Thanks, Richard, also for writing up the nice summary over in bug 1592342. We can collect the duplicates here.

A bit off the wagon but wanted to mention it in case anyone else found this bug and is on TB 70.0b4 with Lightning+Provider for Google Calendar 70.b4. Flipping general.useragent.compatMode.firefox=true on TB 70.0b4 has *totally* resolve a weird stuttering / lagging / slowness issue I've been experiencing ever since moving to 70.0b and now my work machine is snappy and responsive again. Sorry for the noise.

Comment on attachment 9105309
1592407-github-fix.patch

:KWan suggested to use dlob <email address hidden> an author from
https://github.com/kewisch/gdata-provider/commit/216481167586897b5e0949617aca1ee482e5c105.patch

And more comments from IRC:
20:48:13 - Fallen: I'd recommend to use https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams in the Thunderbird patch
20:50:29 - pmorris has left the room (Quit: Ping timeout: 121 seconds).
20:50:59 - Fallen: Something like let url = new URL(aData); let params = new URLSearchParams((url.search || url.hash).substr(1)); and then use params.get("code") instead of results.code
20:51:29 - Fallen: possibly find out if they are using the hash or the search part of the url and then just use the right thing
20:52:24 - Fallen: Maybe a Cu.importGlobalProperties for URL and/or URLSearchParams

Comment on attachment 9105309
1592407-github-fix.patch

Review of attachment 9105309:
-----------------------------------------------------------------

This indeed works, and it's a small fix. We can do other improvements later

Pushed by <email address hidden>:
https://hg.mozilla.org/comm-central/rev/57532519642e
Port OAuth2 decoding fix from gData add-on. r=mkmelin DONTBUILD

TB 71 beta 2:
https://hg.mozilla.org/releases/comm-beta/rev/e4607a1592d21563c3daa8ea441519b63fb5ba62

TB 68.2.1 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/afe823a25c03b91217ff767b360f14e289f3671d

TB 60.9.1 ESR:
https://hg.mozilla.org/releases/comm-esr60/rev/56b6d1b50647143c25efe642b37b02f65f9c4343

Seems to be working in the 68.2.1 build.

Does someone remember if the email (user) used to get pre-filled properly? (It's not atm.)

When testing this fix we should remember to check the other providers too are working.

(In reply to Magnus Melin [:mkmelin] from comment #38)
> Does someone remember if the email (user) used to get pre-filled properly? (It's not atm.)

It is filled in automatically, if the workaround as proposed in comments #20, #22 and #29 is done. I believe to remember that it has been done automatically before Google's recent change, Is I noticed that now I had to check for the user as I do have multiple accounts.

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

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

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

(In reply to Magnus Melin [:mkmelin] from comment #38)
> Does someone remember if the email (user) used to get pre-filled properly? (It's not atm.)
>
> When testing this fix we should remember to check the other providers too are working.

FWIW, in 68.2.0, it *is* possible to set up a new Yahoo! Mail account with OAuth, and the username is prefilled in the web login popup.

You misunderstood: We wanted to test whether TB 68.2.1 with the modification affected OAuth2 authentication of Yahoo, Yandex or others. Apparently that's not the case.

No, I didn't misunderstand. I was just giving a data point that freshly setting up a Yahoo! Mail account with OAuth *did* work in 68.2.0, and the account name was prefilled, unlike with Gmail. The fact that I wasn't talking about 68.2.1 is why I led with "FWIW". Glad to hear the change for Google didn't break Yahoo! or others.

Why is 60.9.1 not released? From a supporters point of view you should not force the upgrade from 60.* to 68.* in this context.

(In reply to Alex Ihrig from comment #46)
> Why is 60.9.1 not released? From a supporters point of view you should not force the upgrade from 60.* to 68.* in this context.

Good questions.
a) we're not forcing updates. we're using the normal update process.
b) we're not doing 60.9.1 as a first choice because what if something goes wrong with that update, or it is insuficient to fix the issue? 68 is a better platform from which to iterate
c) we planned to update users from 60 to 68 anyway

Nevertheless, since 68.x breaks compatibility with so many extensions, many of which will never be updated, it would be a nice gesture to release a 60.9.1, given how severely Gmail and Google Calendar are broken on all prior versions. You wouldn't have to rejigger the update process that's already set to lift people up to the 68.x branch; you could simply make 60.9.1 available under https://archive.mozilla.org/pub/thunderbird/releases/ for those who know to look there.

Of the 5 add-ons that I use:
* 1 was updated (I haven't yet had time to test it).
* 1 was reimplemented as a separate MailExtension by a different author (again, haven't yet had time to test the new version to confirm everything still works).
* 1 was apparently updated to the new packaging requirements, but doesn't actually function.
* 2 seem to have been abandoned by their authors and there's a good chance they'll never be updated or reimplemented.

So with only 2 out of 5 of my add-ons (at least theoretically) working, it'd be nice to be able to keep a working version of 60.x around, and just be aware not to view untrusted emails with it, since it won't be getting any more security updates.

Out of interest: List those five add-ons.

(In reply to Wayne Mery (:wsmwk) from comment #47)
> (In reply to Alex Ihrig from comment #46)
> > Why is 60.9.1 not released? From a supporters point of view you should not force the upgrade from 60.* to 68.* in this context.
>
> Good questions.
> a) we're not forcing updates. we're using the normal update process.
> b) we're not doing 60.9.1 as a first choice because what if something goes wrong with that update, or it is insuficient to fix the issue? 68 is a better platform from which to iterate
> c) we planned to update users from 60 to 68 anyway

You seemed to have forced the update on me! I woke up this morning to a computer that had Thunderbird 60.x running and a dialog box saying to click here to restart Thunderbird with this new (broken) version of Thunderbird. I didn't ask for this ergo I was forced!

Note I had been running the new Thunderbird (68) on a laptop but not my desktop. I was not impressed. Many extensions were broken so I was waiting for them to be updated and working before I would update my desktop but you (thunderbird not you Dan) forced this update on me. Now I'll try to downgrade to 69.0b4...

Ugh, tried 69.0b4 and it screwed up my entire thunderbird installation! Now I have to recover. Thanks guys!

In 'Options' > 'Update':
I have selected 'Check for updates, but let me choose whether to install them'
Thunderbird does as expected. I see a pop up saying there is a new update and asking if I want to update.

If you have the 'Automatically install updates' option selected - note this is selected by default - then Thunderbird will auto update at the appropriate time. You would then prompted to restart.

What do you mean by 'this new (broken) version' ? Do you only mean you are using addons created by various users/authors and those addons are not working ?
If yes, then Thunderbird is not broken. You may discover many addons can be updated / some are in the pipline / some issues can be fixed by alternative ways. Suggest you ask a question in the Support Forum to see if something can be done.

Or
are you refering to the bug discussed in this bug report which claims the update has fixed?
Are you using the up to date addon: Provider for Google Calendar version 68.0
What issue are you experiencing with the Imap gmail account?

(In reply to Andrew DeFaria from comment #50)
> Many extensions were broken so I was waiting for them to be updated and working before I would update my desktop but you (thunderbird not you Dan) forced this update on me. Now I'll try to downgrade to 69.0b4...

Extension authors "only" had about half a year time to update their extensions. IMHO, what isn't updated by now should be considered unmaintained and not fit for use any more.

I really don't understand why after an undesired automated upgrade from 60 to 68 you'd go even further and install a 69 beta 4 version. And then blame others for that "screw up".

It's a loss of functionality nonetheless. In this instance my entire calendar is inoperable! I didn't ask for that so yes I tried to go to a version that might have a chance of getting my functionality back. There was a post that hinted that that 69.01b might work. When I went to the download area I saw 69.04b so I tried that. What I ended up with was a bare-bones installation - no email accounts, no add-ons, nothing.

Have you ever heard of the saying "If it ain't broke then don't fix it"? This wasn't broken until you broke it. And there appears to be no (simple) way back. I didn't ask for my email client of some 17 years to break so horribly. In fact, I was purposely avoiding it by testing it out on another system (laptop). I didn't even get a chance to say "Thanks but no thanks, I'll stay with what is working". AFAICT I was forced into this so Dan's statement of not forcing updates is, AFAICT, false. I've been using Thunderbird since before it was Thunderbird. Yes there are times when add-ons fail to work initially but never has it been this broken WRT Add-Ons in the 17 years I've been using Thunderbird.

And by broke, I do not mean just the add-ons. Granted Google Provider seems busted with OAuth. Google Provider keeps asking me to log in and afterward does nothing but ask me again so yes that's this bug here. I have Version 68 of Google Provider.

What I meant by my environment being screwed up is that when run Thunderbird shows me a basic setup, no accounts, no add-ons, nothing. I'm coming to find out it seems to have created a blank profile instead of using my existing one. But my existing one was still there so using the ProfileManager I was able to log in with the correct profile and I'm cleaning that up.

"Google Provider" is a 3rd-party add-on that hasn't been updated to work with the new Google OAuth2 scheme. Complain to its author:
https://addons.thunderbird.net/en-GB/thunderbird/addon/provider-for-google-calendar/
https://github.com/kewisch/gdata-provider/

In certain upgrade situations it can happen that TB doesn't recognise your existing profile and creates a new one. You can select the profile want in the profile manager or via "Help > Troubleshooting Information", about:profiles. We're working on improving that.

To my knowledge, Thunderbird's Calender Lightning will work in any version you install.

For security reasons we must eventually discontinue old versions and migrate users to the new supported version. The update from 60 to 68 has been a bit bumpy for some users which we regret.

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

(In reply to Andrew DeFaria from comment #54)
> And by broke, I do not mean just the add-ons. Granted Google Provider seems busted with OAuth. Google Provider keeps asking me to log in and afterward does nothing but ask me again so yes that's this bug here. I have Version 68 of Google Provider.

1.) Users should also complain to Google, if there are always technical details changed without specific announcement (to the affected users). This would also be Google's task to inform users - not just developers.
2.) Google Provider must be updated to version 68.2.1, to have the bug in the addon fixed.

> What I meant by my environment being screwed up is that when run Thunderbird shows me a basic setup, no accounts, no add-ons, nothing. I'm coming to find out it seems to have created a blank profile instead of using my existing one. But my existing one was still there so using the ProfileManager I was able to log in with the correct profile and I'm cleaning that up.

That's the bad UX, when we force users to do a major upgrade instead of providing a small bugfix update to 60.9.1 (which is now available today - thanks!).

(In reply to Andrew DeFaria from comment #54)

> Have you ever heard of the saying "If it ain't broke then don't fix it"? This wasn't broken until you broke it. And there appears to be no (simple) way back. I didn't ask for my email client of some 17 years to break so horribly. In fact, I was purposely avoiding it by testing it out on another system (laptop). I didn't even get a chance to say "Thanks but no thanks, I'll stay with what is working". AFAICT I was forced into this so Dan's statement of not forcing updates is, AFAICT, false. I've been using Thunderbird since before it was Thunderbird. Yes there are times when add-ons fail to work initially but never has it been this broken WRT Add-Ons in the 17 years I've been using Thunderbird.

I do not see your reply to Anje on your settings. Was the update contrary to your settings? This is a very core question that has been glossed over.

> What I meant by my environment being screwed up is that when run Thunderbird shows me a basic setup, no accounts, no add-ons, nothing. I'm coming to find out it seems to have created a blank profile instead of using my existing one. But my existing one was still there so using the ProfileManager I was able to log in with the correct profile and I'm cleaning that up.

That is called profile per install and is the "new" way things are done, thank you Mozilla core developers.

(In reply to Jorg K (GMT+2) from comment #49)
> Out of interest: List those five add-ons.

I intentionally did not list them because I prefer not to give out exact details of my configuration when posting under my real name, particularly for pieces of software that are likely to get no more security updates. However, if you want to send me a private message, I'll give you the list.

(In reply to Andrew DeFaria from comment #50)
> Many extensions were broken so I was waiting for them to be updated and working before I would update my desktop but you (thunderbird not you Dan) forced this update on me.

(In reply to Andrew DeFaria from comment #54)
> AFAICT I was forced into this so Dan's statement of not forcing updates is, AFAICT, false.

Andrew, I'm afraid you've got me confused with someone else. Note that the From information for each comment is in a header, not a footer.

(In reply to Jorg K (GMT+2) from comment #53)
> Extension authors "only" had about half a year time to update their extensions. IMHO, what isn't updated by now should be considered unmaintained and not fit for use any more.

"Unmaintained" and "not fit for use any more" are not synonymous. Many Firefox and Thunderbird add-ons have continued working properly for years after their last update. Also, the Thunderbird ecosystem is a lot smaller than the Firefox one, so chances are much greater of a particular specialized add-on being the only one that implements a particular bit of functionality, thus there is a greater chance of needing to rely on a piece of software that hasn't been updated lately. And only a small minority of Thunderbird add-ons have the potential for network-facing security holes, so the argument against continuing to use unmaintained software for security reasons doesn't apply to most of them.

(In reply to Alex Ihrig from comment #57)
> That's the bad UX, when we force users to do a major upgrade instead of providing a small bugfix update to 60.9.1 (which is now available today - thanks!).

Oh! Thanks for the heads-up on that, Alex! I see that not only was it made available under https://archive.mozilla.org/pub/thunderbird/releases/60.9.1/ as I was suggesting, but doing an update in 60.9.0 now updates to 60.9.1 instead of 68.2.0. Very cool; thanks, guys!

(In reply to Matt from comment #58)
> > What I meant by my environment being screwed up is that when run Thunderbird shows me a basic setup, no accounts, no add-ons, nothing. I'm coming to find out it seems to have created a blank profile instead of using my existing one. But my existing one was still there so using the ProfileManager I was able to log in with the correct profile and I'm cleaning that up.
>
> That is called profile per install and is the "new" way things are done, thank you Mozilla core developers.

Ugh, and it doesn't even ask you at install-time if you want to go with your old settings or a fresh profile, the way that such software as the Nvidia drivers, VLC, etc. does it? What a horrendously hostile user experience.

60.9.1 is released

i'm still (or better: recently) having the bug (pretty sure it's the one?)

"auth error while connecting to imap.gmail.com"

never had it before, it just started seemingly yesterday.
please someone help, almost none of my mail adresses work, what can i do? compatmode.firefox had no effect

devschrott,
Which version of TB and Google Provider are you using?

I updated to Thunderbird 68.2.1, Lightning 68.2.1, and Provider for Google Calendar 68.2.1, which are the latest available to me under Ubuntu, and I still have the problem. After the google login, and I click Allow, I get the "Locate your calendar" dialog box, with no calendars in it. The debugging console says:
`[Exception... "null" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gdata-provider/modules/gdataSession.jsm :: login/authFailed< :: line 284" data: no] gdataSession.jsm:284:33`

Note when I tried this in the official release 60.9.0 I got a different error:
`[HTTP/2.0 400 Bad Request 92ms]
Lightning:[calGoogleSession] Authentication failure: {
  "error": "invalid_grant",
  "error_description": "Malformed auth code."
} gdataSession.jsm:272
[Exception... "invalid_grant" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gdata-provider/modules/gdataSession.jsm :: login/authFailed< :: line 274" data: no]`

Note that I was able to log into google/gmail in my browser with the exact same credentials (as in copied/pasted so I know they were identical to what I tried in Lightning

(In reply to David Kramer from comment #63)
> I updated to Thunderbird 68.2.1, Lightning 68.2.1, and Provider for Google Calendar 68.2.1, which are the latest available to me under Ubuntu, and I still have the problem. After the google login, and I click Allow, I get the "Locate your calendar" dialog box, with no calendars in it. The debugging console says:
`Lightning: [calGoogleSession] Authentication failure: undefined gdataSession.jsm:282
[Exception... "null" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gdata-provider/modules/gdataSession.jsm :: login/authFailed< :: line 284" data: no] gdataSession.jsm:284:33`
>
> Note when I tried this in the official release 60.9.0 I got a different error:
> `[HTTP/2.0 400 Bad Request 92ms]
> Lightning:[calGoogleSession] Authentication failure: {
> "error": "invalid_grant",
> "error_description": "Malformed auth code."
> } gdataSession.jsm:272
> [Exception... "invalid_grant" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gdata-provider/modules/gdataSession.jsm :: login/authFailed< :: line 274" data: no]`
>
> Note that I was able to log into google/gmail in my browser with the exact same credentials (as in copied/pasted so I know they were identical to what I tried in Lightning

The easy thing first: TB 60.9.0 will not work (but TB 60.9.1 will).

We just found out that some distributions may have built "Provider for Google Calendar" from the wrong repository :-(

The correct add-on can be obtained here: https://addons.thunderbird.net/en-GB/thunderbird/addon/provider-for-google-calendar/

It's also called 68.2.1 but is may be different. If you're able to open/unpack the XPI file which is just a ZIP file, check the following file:
Open modules/OAuth2.jsm and check line 26: Do you have the working version which reads: `result[key] = decodeURIComponent(value);` ?

But TB 60.9.0 say that provider_for_google_calendar-68.2.1-tb.xpi is not compatible with TB 60.9.0 and cannot be installed.

I've backtracked to TB 60.9.1. When running 60.9.1 I was able to "update" Provider for Google Calendar and it works. The add on says it's version 4.4.2.

I'm gonna stay here on 60.9.x until this blows over.

(In reply to Jorg K (GMT+2) from comment #65)
> The easy thing first: TB 60.9.0 will not work (but TB 60.9.1 will).
>
> We just found out that some distributions may have built "Provider for Google Calendar" from the wrong repository :-(
>
> The correct add-on can be obtained here: https://addons.thunderbird.net/en-GB/thunderbird/addon/provider-for-google-calendar/
>
> It's also called 68.2.1 but is may be different. If you're able to open/unpack the XPI file which is just a ZIP file, check the following file:
> Open modules/OAuth2.jsm and check line 26: Do you have the working version which reads: `result[key] = decodeURIComponent(value);` ?

Yes, my version has that line.

> Yes, my version has that line.

Then it should work. That version of the add-on came from the distro?

(In reply to Jorg K (GMT+2) from comment #69)
> > Yes, my version has that line.
>
> Then it should work. That version of the add-on came from the distro?

No, I added it through the in app "Manage your extensions". Ubuntu doesn't have the Thunderbird extensions as .deb files

(In reply to paul from comment #23)
> I tested the workaround with gData for Calendar and it worked as expected.

Confirmed! /Lars

(In reply to llh from comment #71)
> (In reply to paul from comment #23)
> > I tested the workaround with gData for Calendar and it worked as expected.
>
> Confirmed! /Lars

What is this workaround you mention? I'm still stuck

First of all, TB 68.2.1 with gData 68.2.1 installed from https://addons.thunderbird.net/en-GB/thunderbird/addon/provider-for-google-calendar/ should work. The workaround is described in comment #22.

For posterity: the data that needed to be different was "4/" vs. "4%2F" for the code parameter. It needed to be the latter now. Presumably there was no slash in the code earlier so it would have worked without decoding.

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

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

try this scheduling API https://onsched.com/