After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681727 - Logged in again on goggle account, and still says "Expired Credentials"
Logged in again on goggle account, and still says "Expired Credentials"
Product: gnome-keyring
Classification: Core
Component: general
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
: 691385 (view as bug list)
Depends on:
Reported: 2012-08-13 08:24 UTC by Stef Walter
Modified: 2013-02-15 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Screenshot of problem (33.34 KB, image/png)
2012-08-13 08:24 UTC, Stef Walter
test program (821 bytes, text/plain)
2012-10-04 16:04 UTC, Debarshi Ray
secret-store: Set the schema name correctly on loaded items (8.53 KB, patch)
2012-10-12 15:42 UTC, Stef Walter
committed Details | Review

Description Stef Walter 2012-08-13 08:24:26 UTC
Created attachment 220973 [details]
Screenshot of problem

I was prompted in the notification area to log in again for my Google account. After logging in again, gnome-online-accounst panel still says 'Expired credentials'. See screenshot.

Name        : gnome-online-accounts
Arch        : x86_64
Version     : 3.5.5
Release     : 1.fc18
Size        : 940 k
Comment 1 Debarshi Ray 2012-08-21 16:46:34 UTC
I tried to reproduce this but failed. Here is how I usually test this code path:
+ delete the OAuth token from the keyring using Seahorse
+ invoke EnsureCredentials from d-feet
+ wait for "needs attention" notification
+ start control-center as: /opt/bin/gnome-control-center online-accounts
+ do the log in and refresh dance

This works fine for me.

(I guess, I have been creating and deleting my accounts too often for them to actually expire.)
Comment 2 Bastien Nocera 2012-09-24 09:30:59 UTC
I get the same thing with a Facebook account.
Comment 3 Bastien Nocera 2012-09-24 09:33:11 UTC
$ gdbus call --session --dest org.gnome.OnlineAccounts --object-path /org/gnome/OnlineAccounts/Accounts/account_1340660252 --method org.gnome.OnlineAccounts.Account.EnsureCredentials 
Erro: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._rest_2dproxy_2derror_2dquark.Code400: Bad Request
(According to introspection data, you need to pass `')
Comment 4 Bastien Nocera 2012-09-24 09:52:36 UTC
Each attempt to refresh the credentials end up with a new password/token being added to seahorse instead of the old one being updated.
Comment 5 Debarshi Ray 2012-10-04 16:03:18 UTC
(In reply to comment #4)
> Each attempt to refresh the credentials end up with a new password/token being
> added to seahorse instead of the old one being updated.


secret_password_store_sync is supposed to update values in the keyring, but for some reason it is not. I get the same results with the attached test program.

Stef, are we making a mistake in using the libsecret API ?
Comment 6 Debarshi Ray 2012-10-04 16:04:09 UTC
Created attachment 225827 [details]
test program
Comment 7 Debarshi Ray 2012-10-12 13:45:53 UTC
Reassigned to gnome-keyring after talking to Stef on IRC.
Comment 8 Stef Walter 2012-10-12 15:42:13 UTC
Created attachment 226338 [details] [review]
secret-store: Set the schema name correctly on loaded items

* When we loaded items from the keyring we didn't set the schema
 * This causes any searches for the item that include a schema
   in the search parameters to fail.
 * Also caused problems storing items, when it was expected that
   the item would replace any already stored. This uses a search
 * Fix and add a test for this case, both for encrypted and
   plaintext keyring files.
Comment 9 Stef Walter 2012-10-12 15:42:40 UTC
Debarshi, can you test and/or review this patch?
Comment 10 Debarshi Ray 2012-10-12 16:31:39 UTC
The attached test program and GOA both work as expected.
Comment 11 Stef Walter 2012-10-12 17:47:20 UTC
Attachment 226338 [details] pushed as b7648ca - secret-store: Set the schema name correctly on loaded items
Comment 12 Mehmet Giritli 2013-01-04 10:17:32 UTC
I have gnome-keyring 3.6.2 installed but still have this bug. As I understand it, this fix is in 3.6.2, right?
Comment 13 onip 2013-01-08 10:02:09 UTC
same situation as comment #12 here. Can I provide some information to help test this one further ?
Comment 14 Debarshi Ray 2013-01-09 18:33:54 UTC
Did you check if you have two entries in the keyring for the same GOA account? You can use Seahorse to check. Even with a fixed gnome-keyring, the extra entry does not go away. So you got to manually remove it. :-/
Comment 15 Mehmet Giritli 2013-01-10 09:32:00 UTC
I definitely did it that way and it fixes it temporarily but the main problem was there. More precisely: 

1. I got expired credentials notification
2. Logged back into google and granted access...did not work
3. Deleted the goa account entry using seahorse
4. Logged back into google...worked
5. Some weeks pass
6. I got expired credentials notification
7. Logged back into google and granted access...did not work
8. I have to delete goa account again to make it work....

I thought deleting the keyring goa entries was required only once to fix the problem for good? 

I am waiting for the next time when I get the expired credentials status so that I can try.

BTW: I currently have three goa entries for different accounts: google, facebook and windows...if it makes a difference.
Comment 16 onip 2013-01-12 10:16:43 UTC
same exact situation as comment #15.
Comment 17 Sergio Pascual 2013-01-22 10:29:03 UTC
I'm running Fedora 18 in a virtual machine and the problem persists with the package provided by Fedora

$ rpm -q gnome-keyring

(I do not have entries in the keyring, BTW)
Comment 18 rooksy 2013-02-02 21:36:57 UTC
I was getting this on F17 with G3 and never managed to solve it using the resolutions above.

I now run Fedora 18 (testing-updates) on my lappy and still see this issue on gnome-keyring-3.6.2-3.fc18.x86_64.

Am grepping around in the logs and will post anything interesting.
Comment 19 Stef Walter 2013-02-06 10:59:18 UTC
This is not a gnome-keyring issues. I continue to experience the same issue. Worked on tracing this with Debarshi and we got to the point where Google returned an "Unauthorized" even though the secrets were being retrieved successfully from the keyring.

Using different accounts didn't fix the issue, although using a different machine (also GNOME 3.6) did.
Comment 20 Debarshi Ray 2013-02-11 13:30:18 UTC
I think we are mixing up bug reports. This report was originally about a gnome-keyring bug where there would be duplicate entries for the same key (ie. GOA account). It has since been fixed.

Sometimes, when upgrading from GNOME 3.4 to 3.6, the duplicate entries are left around. Please use Seahorse to check if that is the case. If that is so, then deleting the duplicates and re-creating the account should be ok.

If you are using Google 2-factor then it is a known issue because E-D-S can not use OAuth2 tokens with Google Calendars. See bug 688364

The issue that Stef was having is yet another issue. For some reason Google was not returning a valid access_token with a refresh_token. You can run goa-daemon with REST_DEBUG=all and G_MESSAGES_DEBUG=all, and invoke the EnsureCredentials DBus method on the account object and see if that is the case or not.

If you are encountering the same issue as Stef, then please open a new bug. I am not sure what is causing it because I can't reproduce it on my end.

Comment 21 Guillaume Desmottes 2013-02-11 13:42:04 UTC
*** Bug 691385 has been marked as a duplicate of this bug. ***
Comment 22 Debarshi Ray 2013-02-15 12:35:05 UTC
Ok. Putting it back to gnome-keyring, and closing as the original problem as been fixed. Please open a new bug for your issue. :)