Check that cookies are accepted in Preferences/Privacy & Security, as this is necessary for OAuth2 authentication. If you have gmail mail accounts, the authentication method for the incoming and outgoing should be OAuth2. Remove the passwords from Saved Passwords in Privacy & Security, remove or disable the Provider add-on, restart TB, add the calendar from File/New/Calendar... On the Network... enter your gmail address... the calendar location is autodetected... enter your account password in the OAuth window.

I followed your suggestions and it still ended going down the same error path I described before.

I ensured that cookies were enabled (they were). I removed the stored google related passwords (there were two).

The point where we diverge is that my google login is not a gmail address. It is my own mail domain name. The access url I put in the oauth screen is https://calendar.google.com/calendar/ical/roger.....basic.ics

So the initial oauth just times out and using any of the alternative options just end up failing with the a verification error on a url with a domain of localhost.

I think I am missing something with to do with the changes google recently made to oAuth2.

Roger

That error is an encryption error. I am guessing your web site/ mail / caldav server does not have appropriate SSL certificates.

Matt,

The server is calendar.google.com. I am thinking that it is unlikely they have an out of date cert. The only thing I can think of is that the full url for this (as shown in my previous post) may require me to generate a new key on google in some way, but this is not obvious.

In my trawl about the issues on thunderbird I did find a reference to an OAuth 2 patch that was applied last year. In the comments on the patch there was reference to setting some parameters to cause thunderbird to log the packets it was sending and receiving. But I am struggling to find that again. I tried to capture and analyse the network traffic but it looks like it is being multiplexed into a QUIC connection as an encrypted stream. So any pointers to setting up the internal logging would be helpful.

This was working fine with existing credentials until I did the upgrade.

The CalDAV URL for personal Google calendars is:

https://apidata.googleusercontent.com/caldav/v2/myname@gmail.com/events

so it might work if you enter your domain email address instead of myname@gmail.com. If it does, you should proceed to the OAuth window where you enter your account password.

I tried that and it still does exactly the same as before.

This is driving me nuts now. Can anyone point me at the what I need to put in MOZ_LOG to debug the authorization exchange?

Here is what I see when I run thunderbird from a shell. I have MOZ_LOG set to "negotiateauth:5", log files are created but nothing is written to them. The console output is as follows.

[calBackendLoader] Using Thunderbird's libical backend [LDAPModuleLoader] Using LDAPDirectory.jsm [MsgSendModuleLoader] Using MessageSend.jsm [SmtpModuleLoader] Using SmtpService.jsm console.debug: "Trying to load /usr/lib/thunderbird/libotr.so" console.debug: "Trying to load libotr.so from system's standard library locations" console.debug: "Trying to load libotr.so.5 from system's standard library locations" console.debug: "Trying to load libotr.so from system's standard library locations" console.log: (new Error("Cannot load required OTR library", "resource:///modules/OTRLib.jsm", 109)) console.debug: "Successfully loaded OpenPGP library librnp.so version 0.15.2+git20210806.dd923a4e.MZLA from /usr/lib/thunderbird/librnp.so" console.debug: "Found 0 public keys and 0 secret keys (0 protected, 0 unprotected)" console.debug: "Successfully loaded optional OpenPGP library libgpgme.so.11 from system's standard library locations" console.debug: "gpgme version: 1.14.0-unknown" console.warn: services.settings: thunderbird/hijack-blocklists has signature disabled JavaScript error: chrome://messenger/content/mailTabs.js, line 419: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMessenger.msgHdrFromURI] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] console.warn: Calendar: [CalICSProvider] Could not detect calendar using method attemptDAVLocation - resource:///modules/calendar/utils/calProviderDetectionUtils.jsm:20: AuthFailedError - DetectionError@resource:///modules/calendar/utils/calProviderDetectionUtils.jsm:20:1 @resource:///modules/calendar/utils/calProviderDetectionUtils.jsm:31:7 attemptDAVLocation@resource:///modules/CalICSProvider.jsm:256:13

JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]

I eventually found out how to get some logging out.

1. Go to edit->preferences
2. Scroll all the way to the bottom
3. search for calendar.debug
4. Set both calendar.debug.log and calendar.debug.log.verbose to true

This test was with the username blank and the url set to https://apidata.googleusercontent.com/caldav/v2/myname@gmail.com/events

console.log: Calendar: [CalICSProvider] Trying to detect calendar using attemptHead method console.log: Calendar: [CalDavProvider] Trying to detect calendar using attemptGoogleOauth method console.log: Calendar: [CalDavProvider] Trying to detect calendar using attemptLocation method console.log: Calendar: [CalDavProvider] Checking collection type at https://apidata.googleusercontent.com/caldav/v2/roger@beardandsandals.co.uk/events console.log: Calendar: CalDAV: OAuth token expired or empty, refreshing console.log: Calendar: [CalICSProvider] Trying to detect calendar using attemptGet method console.debug: Calendar:

 CalDAV: recv: Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.

console.log: Calendar: [CalICSProvider] Trying to detect calendar using attemptDAVLocation method console.debug: Calendar:

 CalDAV: send (PROPFIND https://apidata.googleusercontent.com/caldav/v2/myemailaddressremoved/events): 

<D:propfind xmlns:D='DAV:' xmlns:A='http://apple.com/ns/ical/'><D:prop><D:getcontenttype/><D:resourcetype/><D:displayname/><A:calendar-color/></D:prop></D:propfind> console.debug: Calendar:

 CalDAV: recv: 

<errors xmlns="http://schemas.google.com/g/2005">

<error>
 <domain>GData</domain>
 loginRequired
 <internalReason>Login Required.</internalReason>
</error>

console.warn: Calendar: [CalICSProvider] Could not detect calendar using method attemptDAVLocation - resource:///modules/calendar/utils/calProviderDetectionUtils.jsm:20: AuthFailedError - DetectionError@resource:///modules/calendar/utils/calProviderDetectionUtils.jsm:20:1 @resource:///modules/calendar/utils/calProviderDetectionUtils.jsm:31:7 attemptDAVLocation@resource:///modules/CalICSProvider.jsm:256:13

I will be doing more tests. At least I have something to look at now.

Matt, The server is calendar.google.com. I am thinking that it is unlikely they have an out of date cert.

That would be true is that was the link you were connecting to, your screen capture however is using HTTPS://Localhost which a a common redirection used by anti virus programs using their own self signed certificates. But what it is not calendar.google.com. I have no idea why requests are being redirected there,but it may well be something in your firewall or iptables.

This test was with the username blank and the url set to https://apidata.googleusercontent.com/caldav/v2/myname@gmail.com/events

You should not be specifying a location in the URL part of the configuration for google. The developer that authored the change made that quite clear to me. Enter your username and password and let the software determine your calendars.

A test without a user name is next to useless as all it does is fail, you are trying to determine why you are ending at localhost with a certificate error.

You should also delete from the password manager all passwords related to the account and most especially any provider that starts with a guid and contain the words google caldav. as the user name and password stored for the google oath token is not your username or password.

Note1. Only calendars that are enabled for sharing in the google web interface are listed. Note 2. Using the google ICS link on the web will result in a read only calendar. Hardly satisfactory if you want to add or edit anything. Note3. oAuth requires cookies to be enabled to function. Issues with Linux installs occur sometimes as some maintainers still disable them by default.

The flow I see when I add a calendar to Thunderbird is as follows. Note the last is disabled because the calendar is already subscribed.. When does your setup depart from that sequence.

Clicking find calendars opens a Thunderbird browser window as follows.

I skipped the password entry dialog here, but it was followed by and finally with the actual subscribe passed the successfully completed browser authentication back to Thunderbird's account/Calendar which as I said I could not do as the only calendar on the account was already subscribed.

Matt,

I realise that the test I posted was invalid. The very first thing that the attemptGoogleOAuth method does is to check for an empty Username and return a failure. The other methods tried will never work.

Looking at the code for the attemptGoogleOAuth method shows that the only way that a correct URI is constructed is to have one of the preconfigured authentication domains (gmail.com or googlemail.com) in the Location field and the email address that is your google account username in the Username field.

This causes the correct URI to be generated.

console.log: Calendar: [CalDavProvider] Trying to detect calendar using attemptGoogleOauth method console.log: Calendar: [CalDavProvider] Checking collection type at https://apidata.googleusercontent.com/caldav/v2/roger%40xxxxxxx.co.uk/user

The above URI looks good to me. However this reveals what the real problem is on my system.

console.log: Calendar: CalDAV: OAuth token expired or empty, refreshing JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] JavaScript error: resource:///modules/OAuth2.jsm, line 171: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]

This error has been showing up in the console.log all the time but I am afraid I had been ignoring it, assuming it was being caused by incorrect data in the input fields.

Any help in tracking this down would be gratefully received. My first guess this morning is that it might be JRE related. The update to Ubuntu 21.10 that started this saga might have caused that.

Roger

Thunderbird does not use the system JRE.

I did look around for bug and found this https://bugzilla.mozilla.org/show_bug.cgi?id=1705272 which is supposed to be fixed in V89 upwards, but there is nothing to say there is not a regression. That is if you have updated to the V91 release.

How are you setting to the account setup? That bug was specific to accessing the setup from account settings using the account actions button.

Do you see the same on accessing it from the file menu?

Version is 1:91.1.2+build1-0ubuntu1.

I use File/New/Calendar to bring up the username and location popup.

I have used the other routes to get to the popup but they all end up at the same place.

Thanks for the heads up about the JRE.

I will have a look at the bug you found.

Thanks.

The bug does not appear to be relevant.

I am totally out of my depth on this one. I have no prior experience of XPCOM. It looks like error at OAuth2.jsm line 171 is caused by whatever is calling the onStateChange method not having a valid object in the aRequest parameter.

The initial request has been rejected because there is no valid valid OAuth token present. This expected behaviour and causes the redirection. The name property on the aRequest object is missing this causes the failure.

Is this a bug? Is this a documentation error? Having a google login that is not gmail or googlemail email address is not uncommon.

It needs a younger brain than mine (wrong side of 65) to sort this out. I guess I will have to live without my calendar on my linux box.

Thanks for all the help I have received.

My only observation is that is much better to have read previous posts before posting an opinion. It makes threads like this much shorter.

Roger

Then file a bug and see if someone in the development team can confirm that the google user name is a problem. Or is a problem on Linux.

There are many Linux specific bugs that come up and as each distribution is so different often they are distribution dependent. I have even seen bug that occur because of actions taken by maintainers that do not appear on builds downloaded from Thunderbird.net.

If you do file a bug, please post a link here as I would like to follow along, even if I can contribute nothing.

Matt,

My little whinge was definitely not aimed at you. I regretted posting it I soon as pressed the button. It was just a general comment on the development responses showing how it worked with the canned google mail domains. I thought I had made that clear in my first post, but looking at it again now, I realised I had not.

Once again,

Sorry and thanks for your assitance.

I am off to raise a bug now. If I do make it through all the bureaucracy. I do not want to have set up build environment just to report a bug!

Roger

Raised a bug