GNOME Bugzilla – Bug 545015
libedataserverui only remembers 1 password per server/user but ignores different protocols
Last modified: 2012-06-10 14:34:00 UTC
Please describe the problem: libedataserverui only remembers 1 password per server/user but ignores different protocols. I can't have an entry with protocol imap and protocol webdav at the same time. The problem seems to be the following fallback code in e-passwords.c which results in entries with wrong protocol matching: /* XXX We didn't always store protocols in the keyring, so for * backward-compatibility we also need to lookup passwords * by user and host only (no protocol). */ passwords = ep_keyring_lookup_passwords (uri->user, uri->host, NULL, &error); Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Hmm, well the code you pasted was part of a patch to fix the very problem you're describing (bug #354923). What version are you using? (Specify down to the micro number: 2.23.???)
I'm using 2.23.6 (svn revision 9198) I've seen that the code tries to fix that problem I described, but did you actually test it? For me it does not work. Just create 2 new accounts which have no passwords saved yet with different protocols and you'll experience the bug (imap and caldav for example). It's my understanding of the sourcecode that when you request a password now the following happens: The first query contains username, server and protocol, when we don't have a password in the keyring yet this will fail (as it should). Now in old times it seemed that evolution saved the passwords without the protocol part, so to stay compatible with old entries a 2nd query happens. This time protocol is set to NULL. It's my understanding, that this does not only match entries in the keyring without a protocol set but entries with any protocol. So if I already have a password for an imap account and now create a caldav account that 2nd query will ignore the protocol and match the entry for the imap account.
(In reply to comment #2) > This time protocol is set to NULL. It's my understanding, that this does not > only match entries in the keyring without a protocol set but entries with any > protocol. So if I already have a password for an imap account and now create a > caldav account that 2nd query will ignore the protocol and match the entry for > the imap account. You may be correct there. The intent was indeed to match entries with NO protocol rather than ANY protocol. I'll have another look at it, or feel free to submit a patch if you care to.
mbarnes: Found time to take another look on it?
This kind of backward compatibility doesn't worth it, from my point of view. Just remove the code and use protocol always. The most bad thing might be that the user will re-enter his password once again. Nothing wrong with that, I believe.
If it's making life difficult for you, go for it. Evolution already prompts for passwords at inappropriate times anyway, so what's one more?
It's only _once_ more, isn't it? :)
*** Bug 336291 has been marked as a duplicate of this bug. ***
As of Evolution 3.5.3, keyring entries for E-D-S sources are simply filed under the source's unique ID rather than a URI to avoid exactly this kind of mess. Closing as FIXED.