GNOME Bugzilla – Bug 571504
evolution forgets password after LOGIN fail
Last modified: 2010-06-28 09:51:30 UTC
After an authentication failure evolution asks you to type in your password again. I get the message Enter Password of xxx@xxx Unable to authenticate to IMAP server. IMAP command failed: LOGIN failed Please enter IMAP password for xxx on host xxx [ ] [] Remember this password [Cancel][OK] But in my experience the most likely cause of login problems are temporary network issues, so the best course of action is to retry with the password that has worked fine for the past year. If i press cancel, then when i try to check my email again, it asks for the password again. I like to have long complex passwords for email, and i keep them written down at home. If evolution decides to forget a password, then i can't read email until I get home :-( . Some people may not even know their password because, their computer was setup by someone else. I suggest that a retry button be added, or even better, a try last known good password. I am using 2.24.3 on Fedora 10 This bug, or something similar has been around for a long time, and i have seen it in many mail clients.
Evolution tends to forget passwords after ANY failure. We're cleaning this up gradually but we have to do it on a case by case basis, unfortunately. I think I see your point though. The current logic goes something like: 1. Fetch password from keyring. 2. If password not found in keyring: Prompt user for password. 3. Submit password for authentication. 4. If authentication fails: Delete password from keyring. Goto step 1. In other words, we delete first and ask questions later. So the password is already blown away when the user is prompted again, and can't have Evolution retry. What you're suggesting, if I understand correctly, is more like: 1. Fetch password from keyring. 2. If password not found in keyring: Prompt user for password. Add password to keyring. 3. Else if last authentication failed: Prompt user for password with RETRY option. If user provided new password: Replace old password in keyring. Else: Try again with the same password. 4. Submit password for authentication. 5. If authentication fails: Goto step 1. Something like that, anyway. The point being we never delete passwords while authenticating; we only add new ones or replace existing ones. Interesting insight.
Tagging this as an enchancement since it would require some architectural changes.
That flow sounds better, but i think you should only modify the password stored in the keyring if a login is successful. Its probably best to hang on to the last known good password, until you have done a successful login with the new one. I can think of these case in which you may get a login failure 1) the user has changed their password on the server, but not updated the client 2) the server admin has change the password (maybe to lock an account) and not told the user 3) the sever failed for some unknown temporary reason in case 1 the user knows whats going on. they would probably be happy to click through some dialogs to change their password, and test that it works. in case 2 nothing will work, no amount of typing in passwords will help in case 3 retrying will solve the problem. the perfect error message would help the user figure out which has occurred, and help them fix it. (like the firefox address not found page). (i can also think of a tenuous security exploit using the current system. use dns spoofing to pretend to be a users IMAP server. fail a login. hope that the user see a password box and automatically types there system login password.)
Very good point.
I posted another bug report related to the above issue. Which is marked as duplicate. Here is the original post (slightly changed): I am not sure why - but since I use Ubuntu 9.04 I get asked for the password regularly. It's not like every time I use evolution. But every now an then. There must have been an issue regarding the gnome-keyring in ubuntu 9.04 alpha4 - but this seems solved though. Problem: The problem is more fundamental: Every time a login fails the password will be erased. This sucks big time since there are some mail services around (eg. gmx.de) which will not allow more than a limited number of logins per time. If you are logging in to frequently - maybe during testing and relogin (evolution starts with gnome) or may be while waiting for an urgent message and have clicked "Receive / Send" too often. This will result in a erased password. The current behavior has also another drawback: If you are away with your notebook and the password gets erased - you will only be able to use evolution if you have the password at hand. On the other hand if you have it with you - the password might be useless at all - since everybody can use it (in case you don't use a password safe). My recommendation: Chances are good that the password will not change too often. So I think it is a good idea to define it in the profile settings. That makes it possible to change it afterwards and there is no need for a password request anymore. The password should then never be erased. If the password is invalid a warning will be displayed in the new errorlog (I really like this feature - thanks again!) and the user has to change the password manually. With this changes there should be no more annoying password request dialogs.
*** Bug 541224 has been marked as a duplicate of this bug. ***
*** Bug 575753 has been marked as a duplicate of this bug. ***
*** Bug 557506 has been marked as a duplicate of this bug. ***
*** Bug 593745 has been marked as a duplicate of this bug. ***
Any progress? So many duplicates and still Unconfirmed status??
Created attachment 148704 [details] server unavailable today evolution asked for my password following a 'server unavailable 15' error. there is no reason that this would suggest a password change. if i cancel then evo will ask for the password again each time i check mail.
that was with 2.28.1
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 552631 ***
No This is not a duplicate of bug 552631. I know you're trying to be helpful, by going around closing bugs that you think might be similar, but what you're doing is very destructive. Bug 552631 was fixed years ago. This bug continues to occur to this day (the poster above reports it against 2.28.1, but you claim it was fixed in 2.24 !). This bug requires a separate fix, most likely by redesigning Evolution's authentication code as described earlier in the comments. Please look at FIXING this bug rather than marking it as a duplicate and taking the focus away from it. Re-opened accordingly.
> But in my experience the most likely cause of login problems are temporary > network issues, so the best course of action is to retry with the password > that has worked fine for the past year. Nope, it was the right duplicate, based on the initial request. Then the other bug should be opened as "the fix didn't help for xxx". Anyway, the other approach was taken recently, in bug #337479, which may cover this one too. I'm marking this one as a duplicate like before. *** This bug has been marked as a duplicate of bug 552631 ***
No, bug 5522631 is specific to the "resource temporarily unavailable" case which was fixed as a special case years ago. You can even read that in the patch attached to the bug! The bug 337479 that you try to refer people to is about Groupwise, and contains fixes relevant only to the layer of code dealing with Groupwise. I find it very unlikely that IMAP connections go via your Groupwise codebase. In fact almost any problem during email login in various protocols causes Evolution to forget the password, exactly as described in THIS bug. This is a global design bug, as acknowledged by other Evolution developers. [[ It is very important to track these once, and not pretend they are forty different bugs with identical symptoms, even though it may take a lot of work to fix them. If necessary sub-bugs which depend on this one could be created. ]] That problem has clearly become the subject of this bug, I spent some time searching Bugzilla for the best candidate, this was it, except you had closed it -- and the various people CC'd would doubtless like it fixed instead of getting more bug spam proposing to close it unfixed. This problem needs fixing globally cross Evolution. The /approach/ taken in your Groupwise fix is mostly good, but it needs to be everywhere. If you have a patch which takes this approach in all Evolution mail handling code that's great, let's see it.
Please stop doing this and learn to read! bug #337479 comment #18 and those comments with patches below. I'm still sure you chose your bug wrong. *** This bug has been marked as a duplicate of bug 552631 ***
My apologies, on more careful reading I see that your patch http://bugzilla-attachments.gnome.org/attachment.cgi?id=160730 is indeed a broad fix for the wider problem in Evolution that became the topic of this bug and not Groupwise specific as I erroneously characterised it before. The choice to mark this bug as a DUP of 552631 still seems odd to me, but now that is largely academic since the bug is indeed fixed. I apologise re-opening the bug, and thank you for your patience in explaining my mistake.
(In reply to comment #18) > The choice to mark this bug as a DUP of 552631 still seems odd to me, but now > that is largely academic since the bug is indeed fixed. I chose it because of the same version it is reported against (2.23 is technically 2.24) and the same initial issue reported in both.