388578 - CalDAV URL vs. password manager vs. multiple users on the same URL

Status: RESOLVED WONTFIX

(Calendar :: Provider: CalDAV, defect)

Description

[Jakub Klos]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;  Embedded Web Browser from: http://bsalsa.com/; .NET CLR 2.0.50727; .NET CLR 1.1.4322)
Build Identifier: 0.7 pre

If you want to have multiple CalDAV calendars in Sunbird/Lightning which point to the same URL there is not way to have different users access the URL. The password manager always uses the first password for all URLs.

Lets say we have a URL for caldav
http://server/webdav/
And we have 2 different users to access that resource. Lightning will ask only once for the password and will log you in 2x with the same user. 

The main problem is that there is no way to specify a user/password for each caldav URL. I even tried to do:
http://user@server/webdav/
But it is completely ignored and simply it is possible to use only one user on one server.

This should be fixed or changed. The password manager should be used for the complete URL and all sub URLs.
So for instance if the primary URL is
http://server/webdav/~[e-mail]/
It will ask for the password and username and a new URL to
http://server/webdav/~[e-mail]/ 
would require a new password in the manager.
However
http://server/webdav/~[e-mail]/Calendars/ would use already specified password as it is a sub URL of the above.

So to summarize things.
Password manager for caldav should work a bit smarter and consider the primary key not to be the server name but a complete URL and still work for sub URLs.

Reproducible: Always

Comment 1

[Pete Riley]

This is related to bug 247486 and possibly a duplicate.

Comment 2

[Bruno Browning]

Actually, the password manager does not operate on URLs; it operates on (RFC 2617) authentication realms, which strikes me as appropriate for an HTTP-based protocol. It sounds like the unnamed server that you're dealing with also conforms to RFC 2617, and presents both john's and lucy's calendars in the same authentication realm, so the password manager stores a single set of credentials to use when challenged for credentials for that realm. It would be perfectly possible for the server to present those calendars as being in different realms, in which case the password manager would store two sets of credentials and you would be able to log into them separately. Since it doesn't, one has to presume that the server has its own access-control mechanisms that will operate within that realm, allowing e.g. john to access lucy's calendar - under his own login - as appropriate. In the case of CalDAV servers, such access-control mechanisms are actually mandated by paragraph 6.1 of the RFC.

Given the above, my inclination would be that this bug should be WONTFIXed. 

There certainly is overlap here with bug 247486, and I think that most of the problems discussed there should be solved via server-side configuration and access controls, but that bug mostly concerns WebDAV calendars (where RFC3744-style access controls are not mandatory) and partly problems with the way we handle credentials embedded in the calendar URI. So I don't think we can quite dupe these two.

Comment 3

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

Seconding Bruno's decision. Please try to fix this server side (by providing different auth realms) or wait for CalDAV ACLs to be implemented.

Comment 4

[Marc Schütz]

I strongly have to disagree with the previous two comments. While it might be possible to solve this on the server side (which I fortunately was able to do for my use case), other users might not have any influence on the server.

Note also that nothing requires us to allow only one username/password combination for a given realm. Simple look at it as opening a new session to the same server, the same way you could ssh to the same server from inside the same program as different users at the same time (e.g. Putty allows this).

Indeed this a server and a client side solution are both legitimate fixes, and should both be implemented. Please reopen this bug.

Comment 5

[[e-mail]]

Reopen this bug

Comment 6

[[e-mail]]

As Lightning does not support task manager for delegated users and therefore, - your suggestion "fixing this server sides" does not work, I suggest you fix this bug, as it is, - obviously, - not a problem to be assigned on the server side.

Viewing (and editing) tasks of a delegated user only works adding the delegation into Lightning as well and, - therefore, - this bug has to be fixed.

Also see: https://bugzilla.mozilla.org/show_bug.cgi?id=962842

Comment 7

[Philipp Preißer-Kewisch [:Fallen][☁️📆]]

This doesn't have to do with delegation at all. The problem is the http model: each realm has its own user and password. One realm cannot have more than one.

The server side fix is simple: Have the server change the advertised http realm based on the user or calendar that should be accessed.

In another bug we implemented a client side pref that will fake this. Please set calendar.network.multirealm to true in the advanced config editor.