Prompted for CalDAV authentication with password filled in



9 years ago
9 years ago


(Reporter: martin, Unassigned)





9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Lightning/1.0pre Shredder/3.0b3pre

On the the current nightlies (6/28/09 for Lightning, 6/29/09 for Sunbird), I am prompted for a username and password at startup. The username and password in Password Manager work fine, since clicking OK without changing anything logs you in right away.

The Authentication Required prompt does not appear again until the application is closed and reopened.

The CalDAV provider, in this case, is a local Zimbra server. Access is through https. Server SSL certificate is valid and current.

Reproducible: Always

Steps to Reproduce:
1. Create an account on a CalDAV provider, such as Zimbra, that requires authentication
2. Close Sunbird / Lightning
3. Reopen Sunbird / Lightning
Do you possibly have two calendars in the same realm with different account credentials?
Component: Provider: ICS/WebDAV → Provider: CalDAV
QA Contact: ics-provider → caldav-provider

Comment 2

9 years ago
Nope. Very simple setup: The Zimbra account has with a single Calendar. The only account in Sunbird/Lightning is the Zimbra one. In my Lightning install, I don't even have a local calendar setup, just the single Zimbra one.
Interesting, I've seen this with 0.9 but never with 1.0pre. Do you have any special proxy options (specifically the proxy auto-discover options) set up?

Please enable calendar.debug.log and calendar.debug.log.verbose and check the error console for anything special.

Comment 4

9 years ago
I'm not using any proxy at all. Network is just a basic NAT with no port blocking.

Here is the log up to the moment when the Authentication box appears:

[4402]: Warning: unrecognized command line flag -foreground
[4402]: CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="">
[4402]:   <D:prop>
[4402]:     <D:resourcetype/>
[4402]:     <D:owner/>
[4402]:     <CS:getctag/>
[4402]:   </D:prop>
[4402]: </D:propfind>
[4402]: [calTimezoneService] using /Users/mwdiers/Library/Thunderbird/Profiles/bgbumq6t.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/timezones.sqlite
[4402]: [calTimezoneService] timezones version: 1.2009a
[4402]: [calAlarmService] starting...
Hmm. Have you been using your profile since thunderbird 2? Maybe the signon database is borked.

Try renaming signons.txt and signons2.txt (this will make you lose all your saved passwords once) to something else and then saving the password again.

Comment 6

9 years ago
Profile is fresh. Assuming you meant signons.sqlite. I refreshed it just in case. After reentering all my passwords, everything logs in fine. Calendar displays. I then restart Thunderbird, and the Calendar Authentication pops up again, just like before.

Also, the problem occurs in Sunbird as well, which, to my knowledge, shares nothing with the Thunderbird profile. Sunbird installation is fresh out of the nightly from last night, with no previous profile on my system. I installed it just to verify that it was not a Thunderbird interaction. The Sunbird log contains the same Warning as the log I posted from Lightning.

If you wish, I can create an account on our Zimbra server for you to test. Email me at martin at diers dot us, and I can provide details.
Hey, I looked into the issue. For some reason, with your server the password initially sent is my username. This doesn't happen for other servers. Not quite sure yet why this happens. Confirming.
Ever confirmed: true
Summary: Prompted for CalDAV authentication at every startup → Prompted for CalDAV authentication with password filled in

Comment 8

9 years ago
I would imagine that this is true of all Zimbra 5.x servers, then. I am guessing that it has something to do with the way Zimbra requires the URI to be formed, with the username@servername construction.
Why does zimbra require username@server ? I tried without username@ and it let me log in just fine and the password dialog at startup is also gone.

Comment 10

9 years ago
Ok. This is maddening. In the past, I could never get this to work with Zimbra, without the username@servername. This was even in the Zimbra documentation.

Now it works just fine. Should this be resolved, or is this still a bug given that it shouldn't be putting the username in the password field in any case.
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.