1189751 - Calendar does not support saving passwords for two CalDAV calendars hosted on the same server if the username and passwords differ.

Status: RESOLVED INVALID

(Calendar :: Provider: CalDAV, defect)

Description

[Alastair]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

Create two new CalDAV calendars, for example:

https://calendarexample.mozilla.org:5232/user1/calendar.ics/
https://calendarexample.mozilla.org:5232/user2/calendar.ics/

where both calendars have different usernames and passwords, for example let's say user1/pass1 and user2/pass2 for the above URLs. When creating the calendars, I asked Lightning to save the usernames and passwords into the Password Manager in Thunderbird.


Actual results:

Both calendars are created, but only the first calendar prompts for a username and password, and only the first calendar works. The second fails to load any calendar data. The reason is that the Password Manager indexes saved passwords by protocol, domain and port only (not the full URL). In other words, in the Password Manager, you see:

https://calendarexample.mozilla.org:5232/    |     user1     | ...

Note: there is only one entry, and it is for username user1. Consequently, Lightning is presenting user1/pass1 to the server for user2's calendar and this (rightly) fails. My current workaround is to use iptables to port map the calendar server onto multiple ports on the server and therefore I get two entries in the Password Manager; then both calendars work.



Expected results:

Lightning needs to index the username/password combinations in the Password Manager for calendars by URL, not by protocol, domain and port number. Then multiple calendars hosted on the same server would work out of the box.

Comment 1

[[:MakeMyDay]]

Have you enabled calendar.network.multirealm in the config editor aleady to make this feature available?

If so, do you see any messages in the error log? Please enable calendar.debug.log and calendar.debug.log.verbose in the config editor beforehand.

Comment 2

[Alastair]

When I wrote the above bug report, calendar.network.multirealm=false. Keeping this false, and setting calendar.debug.log=true and calendar.debug.log.verbose=true in what follows...

1) I have already created a CalDAV calendar in Lightning which successfully connects with my server.
2) I then created a second calendar (which I called "New Calendar" in what follows) which is hosted on the same server (and hence has an identical domain name and port number) but has a different URL, username and password.

When creating the second calendar, I received the following log message:

CalDAV: Status 403 on initial PROPFIND for calendar New Calendar

In other words, the calendar server denied access to the second calendar, and rightly so, since I have not been asked by Lightning for a username and password for "New Calendar".

Changing calendar.network.multirealm=true does not appear to make any difference when repeating the above: adding a second calendar still does not prompt me to enter a username and password.

Comment 3

[Stefan Sitter [:ssitter]]

I think you need to remove the existing passwords stored for the calendar server from the password manager first. Afterwards Lightning should prompt and store passwords per calendar.

Comment 4

[Alastair]

The following worked: I removed all the calendars connecting to the offending server from Lightning, removed the associated username/password entries from the Password Manager, set calendar.network.multirealm=true, and restarted Thunderbird. I then subscribed to two calendars hosted on the same server, and I am prompted for two separate username/password combinations, one per calendar; these are then saved correctly to the Password Manager. Phew.

Is there any chance you could make this a little easier?! On the web, you generally don't want to be prompted to enter the username and password for each page on a website, but when subscribing to calendars, this is really less of an issue. The UI in Lightning doesn't allow you to "browse" calendars - you've got to enter the exact URL. Perhaps the multirealm mode should be default on rather than off? Alternatively, if you get a 403 Forbidden back from the server when subscribing to a new calendar, perhaps enable multirealm mode, patch up the first Password Manager entry as required, and prompt the user for a new username/password for the second calendar?

Anyway, thanks for all the help, much appreciated. Alastair.

Comment 5

[[:MakeMyDay]]

Thank you, so resolving this WFM based on your above comment.

Enabling this by deafult would have a downside for servers, which deal with one account per user and have implemented an authorization system to access other user's calendars. Just toogling the pref is not enough as you expirienced, that's also a reason, why this is a hidden pref.

But eventually, you may want to contribute and write a brief how-to on this on support.mozilla.org?

Comment 6

[Alastair]

I'm more than happy to write a brief how-to for support-mozilla.org. A URL to some instructions on how to do this and a suggested title and category (if you have them) would be great.

I don't quite understand your downside for servers. If I've understood correctly, with multirealm enabled, the difference would only arise if a user subscribed to more than one calendar from Lightning, and even then they would type in the same username/password combination so the server wouldn't know the difference(?). Or are you changing some headers sent to the server when you enable calendar.network.multirealm? Perhaps CalDAV allows the server to specify multiple URLs to check for a single calendar?

An alternative minimal "solution" would be to spot when there is more than one calendar for the same server and if you get a 403 back from one of these servers then putting up a dialog with a message to say the username/password combination was denied (currently you get nothing explicit about this). Even better, the message could state "do you need to enable calendar.network.multirealm?" as a prompt to find the hidden feature.

Anyway, thanks again, Alastair.