1148320 - "provider expired" error when using a Google Apps account

Status: RESOLVED INCOMPLETE

(Calendar :: Provider: GData, defect)

Description

[Evgeni Golov]

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

Steps to reproduce:

Environment:
Fedora 21
thunderbird-31.5.0-1.fc21.x86_64
thunderbird-lightning-3.3-5.fc21.x86_64
Provider for Google Calendar 1.0.4 (from addons.mozilla.org)

Accessing my private Google calendar works just fine. However, when I try to access a Google Calendar that is connected to Google Apps account, after entering my GApps mail address into the "new session" field and clicking next, only an error message is shown and no login is possible.

Steps to reproduce:
1. Create a new calendar
2. select Google as the provider
3. enter a GApps hosted address when prompted for a session


Actual results:

"This version of the provider has expired, please update to the latest version." error, authentication window stays empty.


Expected results:

The Google authentication window contains the Google login frame and allows me to sign into the account

Comment 1

[Eric]

I have same issue with exact same steps to reproduce and same result.
Environment:
- Fedora 21
- thunderbird-31.6.0-1.fc21.x86_64
- Lightning 3.3.3 (not installed from rpm as original poster, but installed through Thunderbird add-ons)
- Provider for Google Calendar 1.0.4

I enabled calendar.debug.log and calendar.debug.log.verbose and that resulted in these messages in the Error Console.  I can't cut-n-paste from Error Console, so I'm typing them.  I have replaced my email address with "<my-email-addr>".  Error Console messages are:
[calGoogleSessionManager] Creating session <my-email-addr>
[calGoogleSession] Token expired 1428521128 seconds ago, resetting
[calGoogleCalendar] Logging in session <my-email-addr>
[calGoogleCalendar] No access token for <my-email-addr>, refreshing token
[calGoogleSession] Adding item https://www.googleapis.com/tasks/v1/users/@me/lists to queue
[calGoogleSession] Adding item https://www.googleapis.com/calendar/v3/users/me/calendarList to queue
[calGoogleCalendar] Failed to acquire a new OAuth token for <my-email-addr> data: { "error": "http_401" }

Comment 2

[Vít Ondruch]

This seems to be related to bug 1079659 [1]. Probably there should be different client id for GApps?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1079659#c120

Comment 3

[John Dennis]

Same problem:

Environment:

Fedora 21
thunderbird-31.6.0-1.fc21.x86_64
Lighting 3.3
Provider for Google Calendar 1.0.4

FWIW I have two Google accounts each with their own calendar, a personal and a corporate. My personal account and Google calendar access works perfectly. Thus my surprise I could not add my corporate account and calendar.

Comment 4

[Vít Ondruch]

So I got this working, but the solution is quite ugly I must say. So I don't suggest anybody to follow these steps:

1) Setup Gnome Online Accounts for Google Calendar. GOA supports 2 factors authentication just fine.

2) Find GOA's refresh token in seahorse. The one you are looking for is entitled "GOA google credentials ...". When you display the password, at the end, you can find refresh_token string. Please also remember the account identifier, such as "account_1422142860_2", since you'll need it in next step.

3) Find GOA's OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET. You can obtain the GOA's YOUR_CLIENT_{ID|SECRETE} via D-BUS:

$ dbus-send --dest=org.gnome.OnlineAccounts --print-reply /org/gnome/OnlineAccounts/Accounts/account_1422142860_2 org.freedesktop.DBus.Properties.GetAll string:org.gnome.OnlineAccounts.OAuth2Based

where you need to use the account identifier from the previous step.

4) Open ~/.thunderbird/YOURPROFILE/extensions/{a62ef8ec-5fdc-40c2-873c-223b8a6925cc}/gdataSession.jsm in your editor and comment out the gibberish starting by "this" at the end of the file, below the long comment and at the end insert the following lines, where "YOUR_CLIENT_{ID|SECRETE} are the values obtained in previous step.

this.OAUTH_BASE_URI = "https://accounts.google.com/o/";
this.OAUTH_CLIENT_ID = "YOUR_CLIENT_ID";
this.OAUTH_CLIENT_SECRET = "YOUR_CLIENT_SECRETE";
this.OAUTH_SCOPE = "https://www.googleapis.com/auth/calendar https://www.googleapis.com/auth/tasks";

5) Open ~/.thunderbird/YOURPROFILE/extensions/{a62ef8ec-5fdc-40c2-873c-223b8a6925cc}/OAuth2.jsm in your editor and at the firs line of the "connect" function insert line:

this.refreshToken = "1/Byn6zCD57kq1rdxsnmwYAEbLWKI3BT6GUDx_zskwi-s";

Where the refreshToken value is the value obtained in 2nd step.

6) Start the TB and add network > Google calendar > your@email.

7) Optionally, you can remove the line from OAuth2.jsm file again, but keep the lines in gdataSession.jsm


And finally, I started to write plugin (not sure I should publish it ;), which can obtain some of these values via D-Bus from GOA, but I am totally unsure how to integrate this into GData provider :/ I mean, integration into GData is probably not the luckiest way, since we could obtain from GOA more information, not just for calendar.


Phillipp, would you mind to comment please?

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

So this still happens with 1.0.4? I'm puzzled why Google Apps would require a different token type. I just tested this on my own Google Apps account and it works just fine with the built in token, no changes required.

Could you try re-installing 1.0.4 directly from addons.mozilla.org and if it still does not work then enable debugging?

Comment 6

[Vít Ondruch]

(In reply to Philipp Kewisch [:Fallen] from comment #5)
> So this still happens with 1.0.4? I'm puzzled why Google Apps would require
> a different token type. I just tested this on my own Google Apps account and
> it works just fine with the built in token, no changes required.

My normaln GMail account works just fine, the company GMail account does not work.

> Could you try re-installing 1.0.4 directly from addons.mozilla.org and if it
> still does not work then enable debugging?

I tried that of course. My log is exactly the same as in comment #1.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I don't suppose you could get me a temporary company account so I can debug this myself?

Comment 8

[Vít Ondruch]

(In reply to Philipp Kewisch [:Fallen] from comment #7)
> I don't suppose you could get me a temporary company account so I can debug
> this myself?

I don't think this is possible :/

Comment 9

[Evgeni Golov]

(In reply to Philipp Kewisch [:Fallen] from comment #7)
> I don't suppose you could get me a temporary company account so I can debug
> this myself?

I'll try to follow up with our IT, probably not possible but asking is cheap :)

Comment 10

[Vít Ondruch]

(In reply to Evgeni Golov from comment #9)
> (In reply to Philipp Kewisch [:Fallen] from comment #7)
> > I don't suppose you could get me a temporary company account so I can debug
> > this myself?
> 
> I'll try to follow up with our IT, probably not possible but asking is cheap
> :)

Thx.

But what about the idea of using GOA? This would deserve its own ticket probably, but the thing is that GOA can nicely handle 2-factor authentication and SAML, where I can't see how TB would handle that.

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I don't know what client id/secret GOA uses, but the issue with this is that we'd be using someone else's OAuth keys for provider traffic. If there is some version of the Provider that has a major flaw (e.g. making requests in an endless loop due to a bug), there is no way to disable this version using the Provider's API console. Instead, GOA would have to revoke the client secret, potentially breaking down other applications. Or even worse, Google might disable the client.

Comment 12

[Vít Ondruch]

Well, but the thing is that it should be enough to use the authorization key provided by GOA. Refresh of the key is responsibility of GOA as well. So the only thing which can go wrong is GOA. You can query GOA as often as you want in this case and nothing really happens.

I mean, I tried to use just the authorization key provided by GOA, but it expires in 60 minutes and then GData provider tries to refresh the key and it fails, unless I provide also the refresh token and client id/secret.

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Right, but to offer an authorization key, GOA needs to authenticate with Google's OAuth. The auth key is tied to a certain client id/secret combination, so every request being made with GOA's auth key goes onto their account w.r.t quota and accountability.

Comment 14

[Vít Ondruch]

I create separate bug 1168277 for discussion about GOA, since although GOA might we viable workaround for some parties, not everybody can use GOA and people will probably like to see this resolved on its own.

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I'm not sure how to debug this without an account where it fails on. I've tried with both a normal account and a Google Apps account. Usually, it should work with the client ids included. Given you filed a new bug for the GOA enhancement, maybe we can close this one for now to avoid confusion. If the original issue persists, please create a new bug and ideally send me some temporary credentials I can use to reproduce the issue.

Comment 16

[MCZP]

I've managed to make the OAUTH2 authentication pass without an exception by using OAUTH2 module part of thunderbird GRE, it worked flawlessly.
I would suggest to include the GRE version of OAUTH2 as part of the extension for older TB releases where GRE doesn't have it.