GNOME Bugzilla – Bug 578335
CalDAV password not saved in a keyring due to no username in the URL
Last modified: 2009-05-25 16:04:46 UTC
Please describe the problem: Hello, I'm running Evolution 2.26 under Gnome 2.24 on Gentoo x86 stable. I was quite happy that I can now properly edit my Google calendar via CalDAV, however, there's one glitch: the events from the CalDAV calendar don't show up in the panel view. The days with events are not shown in bold, and nothing pops up when I click such a day. Events from other calendars are shown properly. Steps to reproduce: 1. add Google CalDAV calendar with some events to Evolution 2. check the panel calendar 3. -> events don't show up Actual results: Expected results: Does this happen every time? So far, yes. Other information:
Ah, I almost forgot: this happens on two different machines with different compiler settings etc., so it's likely not a Gentoo-related bug.
This may also be related to the fact that the password for the Google calendar is never saved, despite checking the "remember" box..
(In reply to comment #2) > This may also be related to the fact that the password for the Google calendar > is never saved, despite checking the "remember" box.. That could be the reason. Are you using keyring or file passwords? When you run evolution on the console, and you type your password and accept it, will there be any new runtime warning on the console, something with a password? I've such a feeling that this can be caused by my change in bug #562990, as keyring seems to be more demanding than file password store.
I'm using the keyring (which is properly auto-unlocked on login). Here's the runtime warnings which I've got: (evolution:6101): GLib-CRITICAL **: g_utf8_collate: assertion `str1 != NULL' failed (evolution:6101): e-data-server-DEBUG: Loading categories from "/home/echtler/.evolution/categories.xml" (evolution:6101): e-data-server-DEBUG: Loaded 29 categories e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have group 'Passwords-Calendar' (evolution:6101): e-data-server-ui-CRITICAL **: ep_keyring_insert_password: assertion `user != NULL' failed Do you need any other information?
Thanks for the quick response. This is enough information for me. The last warning is the one I caused in the above bug, as a side effect. You compile from sources on Gentoo, do you? If so, could you try to revert the patch from bug #562990, and verify it fixes it, please? (Maybe you realized, I do not use keyring myself, thus storing passwords here works fine for me.)
Hi, I've reverted the patch and rebuilt evolution, but unfortunately the behaviour didn't change at all. I've double-checked that the patch has been really removed.. I've also noticed (presumably) another symptom: when I get an appointment suggestion by mail, I can't add it to my Google calendar; I get an error message about "legitimation failed".
I've just checked my keyring with seahorse, and the password has actually been stored there.. now I'm even more confused. Is this maybe somehow related to the missing group "Passwords-Calendar"?
Try to re-setup your CalDAV account, it probably still uses URL without the user name. (I'm sorry, I forgot to mention before.) What's the key for the password? The passwords-calendar group is, I think, from the file password store, as it tries to read passwords from there, in case of migration from file password store to keyring store. Some thing like that was done some time ago.
Yep, removing and re-adding the CalDAV account did the trick - many thanks! Now the password is stored and the panel calender shows the events as expected. The key is 'caldav://florian.echtler@gmail.com@www.google.com/calendar/dav/florian.echtler@gmail.com/events', whereas the key from my previous CalDAV calendar was just 'google://florian.echtler@gmail.com' .
Hmm, the later is for the Google calendar account, so it explains why it couldn't find for the CalDAV, it wasn't there at all. Thanks for all the investigation, I'll revert the patch from the other bug in some way and write here since which version it is done.
Created attachment 133508 [details] [review] committed evo patch for evolution; A bit extended finally, as change of URL dropped username part too (even before my "fix" in the previous bug.) It's enough to just change a username or url to fix the source, and next start everything should be back in normal.
Created commit 8da8026 in master. Created commit 26fb7a6 in gnome-2-26.
Reopening, as username containing @ garbles URL.
Created commit c37d828 in evo master. (since 2.27.3) Created commit c6b3f19 in evo gnome-2-26. (since 2.26.3)
Oops, those above commits for '@' in username. (I forgot to mention).