Created attachment 923495 [details] Screenshot of "Password was incorrect" message in the "Authentication request" dialog Description of problem: I'm seemingly unable to get the "Authentication request" dialog to accept the password for my Google account. Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. open Online Accounts (in Settings/control-center) 2. Go through the process of adding a Google account, entering your password in the process 3. After succesfully adding the account and in the subsequent "Authentication request" dialog with the email address of the previous Google account you added, enter your password again. Actual results: You get a "Password was incorrect" message with yellow text in the "Authentication request" dialog Expected results: The password being correct as it is the same correct password I used in step 2 Additional info: I also get this "Authentication request" dialog whenever I log in, with the same results after trying to enter the password. This is the same bug as bug 1126132 but that bug is filed against the wrong component (gnome-keyring), I think.
*** Bug 1126132 has been marked as a duplicate of this bug. ***
I have a similar problem, which is manifesting itself in Evolution. I believe this bug is related to 1124291 and 1125964, which are tagged gnome-online-accounts. I have had an authentication dialog, apparently system modal, that pops up at login. This dialog asks for my gmail account password. It does not accept the valid password, and pops up again. I cancel it, and continue. This dialog has been appearing for about a week. Today is the first time I have been unable to check imap mail using evolution. Edit->Preferences->MailAccounts->OpenOnlineAccounts is unable to log into gmail, and Evolution will not work. Should I continue with this bug, or file another one, perhaps on Evolution ?
Same issue here. Delete and re-add of the account does not help. During the re-add when the dialog box containing the google html authentication appeared, the password was accepted, but the gnome dialog reappeared immediately afterword.
This is a bug in evolution-data-server, popping up the password dialogue when it shouldn't. See also: https://bugzilla.gnome.org/show_bug.cgi?id=728496
I'm wondering how much this is related to [1]. In any case, due to an existence of an upstream bug report, let's move there [2], to avoid work duplication. [1] https://bugzilla.gnome.org/show_bug.cgi?id=735311 [2] https://bugzilla.gnome.org/show_bug.cgi?id=728496
I did a build similar to the one mentioned by Frank Dana in https://bugzilla.gnome.org/show_bug.cgi?id=735311#c7 and the issue seems to be resolved, so after loggin in or clicking on the clock the password dialogue no longer is popping up. So is there any chance to get the fix for bgo #735311 backported to 3.10.x?
Okay, you are right. I took the upstream patch (as attached in the comment you cited) and added it into evolution-data-server-3.10.4-5. I'll create an update with it as soon as it's built (you'll see automatic comments from the update software).
evolution-data-server-3.10.4-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/evolution-data-server-3.10.4-5.fc20
evolution-data-server-3.10.4-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Unfortunately the cure appears worse than the disease... I can reproduce the original problem here: evolution-data-server-3.10.4-4.fc20 won't let me give an imap password for a mailbox on demand. It *does* prompt for missing imap passwords at startup, but not afterwards. evolution-data-server-3.10.4-5.fc20 does prompt for passwords on demand... and at every other opportunity. It appears to do so on every imap connection (the only exception being one authenticated via GSSAPI.) Even passwords already cached in the keyring are prompted for at startup. And they are prompted for again every time a connection restarts due to any form of timeout. I typed the same password for the same account about 15 times yesterday. Back to 3.10.4-4.fc20 today for me, as the 4-5 behaviour is really unusable. Want me to reopen this BZ or submit a new one? It's not _exactly_ the same problem but is clearly an issue in the same general functionality, and it is a regression that only cropped up with this fix. Thanks!
Thanks for the heads up, though I do not think the fix as such is related to the issue. There happens sometimes (very rarely) that the evolution-source-registry lost connection to the keyring, which provides passwords. Such lost connection (despite it being only local) exhibits the issue you described. There usually helps to restart the evolution-source-registry process. This process is running in the background whole time a user is logged in, which means if you updated the evolution-data-server process and started evolution to see the outcome, then you actually didn't use the updated binary, but still the old, from the previous package version. The safest method to get up-to-date packages in action is a computer restart.
(In reply to Milan Crha from comment #11) > Thanks for the heads up, though I do not think the fix as such is related to > the issue. There happens sometimes (very rarely) that the > evolution-source-registry lost connection to the keyring, which provides > passwords. Such lost connection (despite it being only local) exhibits the > issue you described. There usually helps to restart the > evolution-source-registry process. I don't think that's the issue --- I updated evo-data-server on Tuesday evening before shutdown, and had the password issues after fresh boots on the subsequent two days.
Could you update to the latest evolution-data-server, reboot the machine, then login, run a terminal and do the following, please: a) run evolution-source-registry from a terminal: $ /usr/libexec/evolution-source-registry b) stop anything else currently running; it's what: $ ps ax | grep evolution returns, which might be evolution-calendar-factory, evolution-alarm-notify; do not stop the evolution-source-registry, which should be the one from step a); also kill the calendar factory as the last, because gnome-shell may restart it for you c) then try to reproduce, while watching console output on the terminal from a) There should be some AUTH lines with requests and responses, and in case of errors with an error message too. I hope it gives a little clue what is gong on here. The evolution-source-registry uses gcr library, which has its own debugging options, which I do not know off-head, I'm sorry.
(In reply to Milan Crha from comment #13) > Could you update to the latest evolution-data-server, reboot the machine, > then login, run a terminal and do the following, please: > a) run evolution-source-registry from a terminal: > $ /usr/libexec/evolution-source-registry > > b) stop anything else currently running; it's what: > $ ps ax | grep evolution > returns, which might be evolution-calendar-factory, > evolution-alarm-notify; > do not stop the evolution-source-registry, which should be the one from > step a); also kill the calendar factory as the last, because gnome-shell > may restart it for you > > c) then try to reproduce, while watching console output on the terminal from > a) > > There should be some AUTH lines with requests and responses, and in case of > errors with an error message too. I hope it gives a little clue what is gong > on here. The evolution-source-registry uses gcr library, which has its own > debugging options, which I do not know off-head, I'm sorry. I've been having a problem similar to the one mentioned where Evolution keeps popping up the authentication modal over and over and not accepting my password. Let me describe what just happened to me now. 1. I'm using Evolution successfully, reading mail, sending mail. 2. Suddenly either sending or reading fails due to auth error. 3. Auth modal might pop-up here, might not. Mostly if it does pop-up it will not accept my password. 4. I close the Evolution client window. 5. Go into Alt+F1 to restart Evolution and now one of two things can happen. I. Evolution might come up in the search field normally and I restart it. II. The auth modal might pop-up here and it always refuses my password. 6. Once Evolution is started again, usually by cancelling the auth modal, it mostly works again without errors. Sometimes it might not work and I have to wait a while longer for it to start working again. Also I can get the auth modal with no provocation at all, and my password always fails. Yet if I just start the Evolution client window I can read and send e-mail. Until the situation above occurs. So I tried doing the steps you describe Milan and here are my results. 1. I made sure evolution-data-server was the latest version already. 2. I reboot 3. I start /usr/libexec/evolution-source-registry from a terminal without errors 4. I kill all evolution- processees except my source-registry process. evolution-calendar-factory is immediately restarted and I leave it alone. 5. After this Evolution works fine for a long time, but this is not unheard of. 6. After a long time of working, even fetching new mail, I tried to open one of the new mails that had come in and there comes the auth modal. The difference I see in the evolution-source-registry stdout is here on the last line. AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (DISMISSED) Only additional information I can give is that between the many SUCCESS reports and the DISMISSED report when the auth modal came up I have closed the laptop causing my OpenVPN to terminate. I have then re-opened the laptop, and re-connected my OpenVPN which I use out of habit when I am not home. I mention this because nothing else strange has happened to the system and I have a feeling that all other times that the auth modal has come up and refused to accept my password, that those times have also been associated with closing and opening the lid and re-connecting the OpenVPN. This particular VPN redirects default gateway so it affects all traffic and has its own DNS.
(In reply to Stefan Midjich from comment #14) > (In reply to Milan Crha from comment #13) > > Could you update to the latest evolution-data-server, reboot the machine, > > then login, run a terminal and do the following, please: > > a) run evolution-source-registry from a terminal: > > $ /usr/libexec/evolution-source-registry > > > > b) stop anything else currently running; it's what: > > $ ps ax | grep evolution > > returns, which might be evolution-calendar-factory, > > evolution-alarm-notify; > > do not stop the evolution-source-registry, which should be the one from > > step a); also kill the calendar factory as the last, because gnome-shell > > may restart it for you > > > > c) then try to reproduce, while watching console output on the terminal from > > a) > > > > There should be some AUTH lines with requests and responses, and in case of > > errors with an error message too. I hope it gives a little clue what is gong > > on here. The evolution-source-registry uses gcr library, which has its own > > debugging options, which I do not know off-head, I'm sorry. > > So I tried doing the steps you describe Milan and here are my results. > > 1. I made sure evolution-data-server was the latest version already. > 2. I reboot > 3. I start /usr/libexec/evolution-source-registry from a terminal without > errors > 4. I kill all evolution- processees except my source-registry process. > evolution-calendar-factory is immediately restarted and I leave it alone. > 5. After this Evolution works fine for a long time, but this is not unheard > of. > 6. After a long time of working, even fetching new mail, I tried to open one > of the new mails that had come in and there comes the auth modal. > > The difference I see in the evolution-source-registry stdout is here on the > last line. > > AUTH (1405335377.24858.1@zakalwe): Initiated > AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) > AUTH (1405335377.24858.1@zakalwe): Initiated > AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) > AUTH (1405335377.24858.1@zakalwe): Initiated > AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) > AUTH (1405335377.24858.1@zakalwe): Initiated > AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS) > AUTH (1405335377.24858.1@zakalwe): Initiated > AUTH (1405335377.24858.1@zakalwe): Complete (DISMISSED) > 1. Additionally I closed Evolution. 2. Hit Alt+F1 to open it again and before I could type "evol..." in the search field the auth modal popped up, and refused to accept my password. 3. I Cancel the auth modal 4. Start evolution again. 5. New auth modal, it accepts my password! 6. Evolution works as expected now. During these last additional steps I see the following info in evolution-source-registry. AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (ERROR - Bus name vanished (client terminated?)) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (DISMISSED) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (DISMISSED) AUTH (1405335377.24858.1@zakalwe): Initiated AUTH (1405335377.24858.1@zakalwe): Complete (SUCCESS)