GNOME Bugzilla – Bug 727247
Don't ask user for credentials for accounts from Gnome Online Accounts, ask goa-daemon instead
Last modified: 2015-03-10 11:56:40 UTC
Sometimes, evolution prompts for password for my gmail account that is defined in Gnome Online Accounts. This is actually harmful: user's master password will be stored in not-exactly-secure gnome-keyring (goa saves it's own app-specific authorization code) and with high odds, it won't work for the user anyway. The correct behaviour is to ask goa-daemon for new credentials and if user needs to provide input, goa should request it, not it's client app (evo in this case). Evolution 3.10 @ Fedora 20
I don't know why or how it would be asking for a password. The GOA integration already works exactly the way you describe that it should work.
Interesting. I get a gnome-shell/clutter dialog window asking for gmail password for evolution, similar to one that evo uses to ask for GPG passphrases. Given pervasiveness of these dialogs (you can't defocus them to find out what happened), how to debug what does invoke these windows?
I'd first check Evolution's account list to make sure you don't have an old non-GOA Google account configured. You might even want to peruse the files in ~/.config/evolution/sources, which is where the raw account data is stored.
This is still happening with 3.12, even with a new install (using gen7 goa identities). Sometimes the shell asks for passwords to the registered Google accounts; no matter what is entered, the first try fails and the second seems to succeed. An "Evolution Data Source" entry for the account is added to gnome-keyring. I think it might be the calendar component.
This is still happening on evolution-3.12.7 and gnome-online-accounts-3.14.0. I get periodically asked for a password for each of my two Google accounts. It logs the following: Out 23 11:06:21 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Initiated Out 23 11:06:22 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Initiated Out 23 11:08:05 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Complete (DISMISSED) Out 23 11:08:05 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Initiated Out 23 11:08:05 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Complete (DISMISSED) Out 23 11:08:05 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Initiated Out 23 11:08:05 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Complete (DISMISSED) Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Complete (DISMISSED) Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Initiated Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1369102570.927.0@kristen): Complete (DISMISSED) Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Initiated Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Complete (DISMISSED) Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Initiated Out 23 11:08:06 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Complete (DISMISSED) Out 23 11:08:07 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Initiated Out 23 11:08:07 kristen org.gnome.evolution.dataserver.Sources3[993]: AUTH (1395402979.1174.0@kristen): Complete (DISMISSED) I should stress that all those log messages correspond to *two* canceled password prompts, one per Google account. In my case, I don't even have anything to enter on that box since I have two-factor authentication enabled.
I believe this is bug #728496, which is currently widely occupied by more reporters. Please note that the upcoming 3.16.0 will have this authentication done differently, where I believe it'll also fix this issue, though I have no prove for it, because I was never able to reproduce it myself. *** This bug has been marked as a duplicate of bug 728496 ***