475188 - when using multiple google caldav calendars from different accounts (personal/app) only one password is saved

Status: RESOLVED DUPLICATE of bug 247486

(Calendar :: General, defect)

Description

[arvind]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.5
Build Identifier: Lightning 1.0pre with Thunderbird 3 Beta 1

i have two google calendars subscribed in lightning: one from a personal account, and one from a work (google apps) account.

when i add the two calendars and save a password, lightning/thunderbird store only the password for whatever account is added first, storing passwords at the domain level. however, the two calendars are loaded from the same domain (calendar.google.com), but use different URLs corresponding to different accounts & passwords.

So, the first saved password is applied to all the google calendar accounts, and authentication fails (the calendar shows an error mark with the tooltip 'this calendar is momentarily unavailable'). 

Reproducible: Always

Steps to Reproduce:
1. add a google calendar through caldav
2. lightning asks for authentication details
3. provide authentication details, and store the password
4. add another google calendar that belongs to a different account
5. lightning does NOT ask for authentication details, and the calendar load fails
6. remove the first google calendar and remove the saved password: restart thunderbird
7. lightning asks for authentication details for the second (non-loading) calendar
8. the second calendar loads
Actual Results:  
only one password is saved, and lightning attempts to apply it to all google calendar caldav accounts - authentication fails and only calendars belonging to one account load

Expected Results:  
lightning/thunderbird should save google caldav passwords identified by the calendar url and not by the domain. 

i don't know if this is an architectural problem with thunderbird or with lightning, but this should be an increasingly common case now that services like google calendar are being used for both business and personal use.

Comment 1

[Bruno Browning]

From a protocol standpoint, this is the way that CalDAV calendars are supposed to work. CalDAV servers typically present themselves as a single HTTP authentication realm (viz. RFC 2617). Clients should use a single credential set against this single realm; and if principal A needs to access calendars belonging to principal B the proper way to do so is to use principal A's credentials, with access to principal B's calendar being allowed by server-side access controls. I haven't used Google calendars enough to know how to configure such access, but IMO this is not a bug.

Comment 2

[arvind]

ah, but from a user's standpoint this is a bug!

i have no problem with what the caldav specification says. in this case, principal A IS principal B, but the accounts belong to different systems. in google, i can give my personal account access to my work account, but that is a huge confidentiality risk: what if my personal account gets hacked?

thunderbird handles authentication to mail servers in much the same as i would like calendars to be handled. i can have two email accounts in the same domain, and thunderbird stores them as separate accounts with separate authentication details. so why not do the same with calendars? i believe apple's iCal follows this method...

so perhaps the problem is that in lightning, remote calendar accounts are not a first-class citizen.. a much better access model would be to store calendar accounts (which can own multiple calendars) and apply authentication details to each calendar as appropriate?

Comment 3

[arvind]

i guess i should restate the 'expected results': as a multiple account holder, the expected result should be that calendars belonging to different accounts are appropriately authenticated, and load properly for read-write access

Comment 4

[Bruno Browning]

I disagree that this is the desired behavior.

Say I am boss B* and have administrative assistant A*. I often need A* to perform scheduling actions on my behalf, and I want the scheduling messages that get passed around to contain information saying essentially "this is A* acting on behalf of B*", not "B* did this". CalDAV scheduling has this built-in, and it relies on A* using his own credentials to authenticate to the server, which is configured to recognize the A*~B* proxy relationship and allows A* perform certain actions, as A*, on B*'s account. This would be impossible if A* were accessing B*'s resources using B*'s own credentials. I think that the "IMAP model" of credentialing is broken in this context, and that what we need to do is let CalDAV be CalDAV, not force it to behave like IMAP. I should also point out that this model is not something with which people are unfamiliar: I expect that most people today use some variation of SMB to do file-style access to server resources, and most implementations of SMB allow users a single credentialed connection per server, with resource access mediated by ACL just as CalDAV is designed to do. 

Still, the IMAP mindset does seem to be pervasive, in part perhaps because in Lightning we are presenting CalDAV calendars alongside IMAP accounts. This bug has been opened and closed at least three times before. So, while I think that breaking the HTTP authentication model by using multiple credentialsets per authentication realm is a bad idea, I would be comfortable morphing this bug into a "need UI for CalDAV proxy relationships" or something along those lines. At this I don't realy have any suggestions concerning that UI, but I think we need it. In some ways, Google exacerbates this problem by attempting to put a few billion calendars in a single authrealm - but to my mind that argues for a Google-specific extension, not for modifying the behavior of the base product or that of the CalDAV provider.

Comment 5

[arvind]

I don't think the case I'm talking about involves Boss B and admin assistant A. And I suspect because we're talking about a tool in a communication context, and communication systems are full of accounts and account-style models. If I were designing this, I'd prefer to support a diversity of user mental models than adhere to a standard that doesn't support real world use. (btw, iCal doesn't force me to have only one auth set per authentication realm; if I used a mac daily, I would end up using it just for that reason, even though I prefer integrated calendaring; having bad access to all my calendars is better than having excellent access to only one).

However, I'm not an engineer, and I don't know anything about Lightning development, so if for whatever reasons fidelity to the CalDAV standard is important, fair enough. 

Without belabouring the point, how do we move this forward? While I can't code and I know nothing about Lightning architecture, I can design UIs.

Does this involve opening a new bug? If I design wireframes and screens would I just attach them to the bug?

Comment 6

[Chef Chaudart]

I find myself with the same problem.

Ho Can I share calendar with my wife and children ?

Currently it works only with the 2 first created, my wife and my first child.

Password is stored only for my wife !?  And creation of third calendar didn't asked for an identification.

Comment 7

[Gary Brooks]

I feel that I may be belabouring some of the above points.  I work for several companies simultaneously, 3 of which have google apps calendars, to be effective I need to be able to see all the data in one point - in my case Sunbird.  It strikes me that a URL is not just a domain and sealing off authentification at the domain level is artificial - whether or not it happens to work in most circumstances.

Therefore this is a bug.

Comment 8

[arvind]

Is there any calendar standard that works with *multiple* calendars for the same account? So far, I've only seen calendars identified individually, through the URL. In the google case, there can be multiple calendars associated with each account - is there any standard that 'autodiscovers' them? currently I have more than one calendar in my work account (corresponding to multiple projects) - and I have to add each one one by one. maybe this is why a google-specific extension comes in handy - manage and sign in multiple identities and retrieve/list their associated calendars..

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

iiuc then this bug needs to implement caldav ACLs. This is a major enhancement and I doubt this will happen in the 1.0 timeframe. We'll surely take it for 1.0 if a patch shows up.

ludovic might be looking into this.

Comment 10

[Nathaniel McCallum]

This bug is a duplicate of the 5 year old bug #247486.  Please fix it asap, it is painful...

Comment 12

[Chetan Chauhan]

I can think of a simple solution to this problem.

Make thunderbird password manager to respect the username field in a URL.
For example i create a calender pointing to 
http://chetan@<my-calendar.com>/caldav.php/chetan/home
However when it comes to authenticating , thunderbird basically chucks the username out and lets me authenticate with anything.

Thunderbird respects the username field in IMAP and stores different passwords accordingly. Lightning and thunderbird should work the same way and store passwords INCLUDING and respecting the username part of the caldav URL.

Personally i'm quite surprised that all the architectural changes in TB 3.0.x with "gecko 1.9.x" this is left out. Presently i'm forced to use wildcard hostnames on my CALDAV server. http://<username>.calender-server.com works great with TB 2.x and 3.x .

Comment 14

[Andrew McMillan]

As noted in comment #10 this is a duplicate of #247486 and seems to be a very common desire