GNOME Bugzilla – Bug 681727
Logged in again on goggle account, and still says "Expired Credentials"
Last modified: 2013-02-15 12:40:41 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
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.)
I get the same thing with a Facebook account.
$ 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 `')
Each attempt to refresh the credentials end up with a new password/token being added to seahorse instead of the old one being updated.
(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. Right. 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 ?
Created attachment 225827 [details] test program
Reassigned to gnome-keyring after talking to Stef on IRC.
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 correctly. * 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 internally. * Fix and add a test for this case, both for encrypted and plaintext keyring files.
Debarshi, can you test and/or review this patch?
The attached test program and GOA both work as expected.
Attachment 226338 [details] pushed as b7648ca - secret-store: Set the schema name correctly on loaded items
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?
same situation as comment #12 here. Can I provide some information to help test this one further ?
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. :-/
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.
same exact situation as comment #15.
I'm running Fedora 18 in a virtual machine and the problem persists with the package provided by Fedora $ rpm -q gnome-keyring gnome-keyring-3.6.2-2.fc18.x86_64 (I do not have entries in the keyring, BTW)
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.
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.
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. Thanks!
*** Bug 691385 has been marked as a duplicate of this bug. ***
Ok. Putting it back to gnome-keyring, and closing as the original problem as been fixed. Please open a new bug for your issue. :)