Closed Bug 247486 Opened 21 years ago Closed 13 years ago

can't load several calendars with different passwords on same server/realm

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

Product:
Calendar
Component:
Provider: ICS/WebDAV
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mik77, Assigned: Fallen)

References

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(2 files)

Fix - v1
4.47 KB, patch
mschroeder
: review+
Details | Diff | Splinter Review
Pref off - v1
3.67 KB, patch
mmecca
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514

Now the passwords are stored in the password manager. If you have different
accounts on the same server with several calendars in each account you must
choose *one* account at Calendar startup. You can only load calendars from this
one account all others fail.
When the passwords were stored in CalendarManager.rdf this worked. The password
manager is the better way, but it must save the username/password for each
calender separately.

Reproducible: Always
Steps to Reproduce:
one server
several accounts with passwords
calendar in each account
subscribe to all
try to load them on startup

Actual Results:  
only calendars from one account are loaded

Expected Results:  
load all calendars
Are the calenders on the same url?
What happens when you use the http://username@server/path syntax for the url?
(include the username)
afaik, password manager uses the url as the key.

The calendars have the same URL https://mediacenter.gmx.net/calendarname.ics
(file  names are different).
But in the password manager it ist called only "mediacenter.gmx.net:443 (GMX
MediaCenter)".
When I try https://username@mediacenter.gmx.net/calendarname.ics it is also
stored with the name "mediacenter.gmx.net:443 (GMX MediaCenter)" without the
username.
So I get 404 errors for all calendars but one.

Background: I have my private account with my private calendars and one account
I share with some other members of my team.

I can't use them both at one time with the new Calendar build.
This isn't a password manager problem. Password manager only saves tha password
for the next time you need to login, so the next time mozilla is started
During one session, necko stores the credentials and reuses them the next time
the url is accessed.
Before, necko got the full credentials from calendar, and used them. Now it asks
password manager (or the user) the first time, and then caches them.

You could try to use https://username:password@domain/ as url. It is unsafe,
because the password is stored in plain text, but it has always been that way.
This workaround works. But a solution that would use the password manager to
store the passwords would be much better.

Nevertheless bug 247490 prevents me from using the latest builds :-(
*** Bug 248208 has been marked as a duplicate of this bug. ***
QA Contact: gurganbl → general
Is anybody actually working on this?  In a group environment, to have passwords
on display as per the workaround isn't a viable solution, and this is stopping
us deploying Calendar for customers.  If, as stated, there is no problem in
Password Manager, where in Mozilla can this be implemented?
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Component: General → Provider: ICS/Webdav
QA Contact: general → ics-provider
I've been trying to reproduce this but don't have a webdav-server with different rights to calendar-files, going to try to set this up soon. For the devs: ftp-url's get stored with full url like:
ftp://bas@server  -  username: bas   - password: pwd1
ftp://susan@server - username: susan - password: pwd2

while webdav is stored with just the name (without using http://bas@ ). If the storing of the servernames in webdav could be the same as with ftp this would be solved (and some other bugs too I think)
Did some testing with webdav as this was a question in the forums:
http://forums.mozillazine.org/viewtopic.php?t=531019

I have lightning 0.5pre (2007031405) installed. My initial setup was one webdav-share with 4 calendars -> the password gets stored and it only has to be entered once. I also have a setup with two webdav-shares on one domain. Both shares have different webdav-realms and different users -> no problem. Then I gave the two authentication-realms the same name -> things get messy.
The passwordmanager stores the passwords as:
domain:port (Realm) Username

putting the username in the url (http://user@domain/file.ics) doesn't do anything.

So, at least with the latest version of lightning, there seems to be no problem with webdav, if you deploy it correctly. This means you have to set the permissions in webdav, not in the filesystem of the remote server. Also, if you use different directory's you should use different realms...

FYI, I also tried using the system with two shares with the same name and giving the urls with:
http://user:pass@domain/file.ics

This seems to work correct for the first url but the second one fires an empty user/pass dialog even though the password is remembered. 
regarding the last sentence, this seems to be correct insofar that the user/pass which is stored in memory by the first url is not correct for the second. However, this means that the credentials from the url aren't used (as I also experienced with the user@domain urls). Also, the username from the url doesn't get pushed to the password-dialog. 
Here is my experience with the problem, using the Lightning 0.3.1 release and Thunderbird 2 beta 2.

To reproduce:

1) In Lightning, "delete" all of your remote calendars of the relevant webdav server.

2) In "Thunderbird > Tools > Options > Privacy > Passwords > Edit Saved Passwords", remove each entry for this webdav server.

3) Restart Thunderbird.

4) In Lightning, "create" a new webdav calendar.  In my case, the webdav server is "dav.messagingengine.com", and for privacy I'll pretend that my username is "user1@fastmail.fm".  So, I specify the Location URL as:  https://user1@fastmail.fm@dav.messagingengine.com/user1.fastmail.fm/files/calendars/Pete.ics

I'm then prompted to "Enter username and password for "dav.messagingengine.com" at "https://dav.messagingengine.com"", which I do (and also tell Password Manager to remember it).

5) Repeat step (4), but replace all occurrences of "user1" with "user2", and change "Pete.ics" with "SomeoneElse.ics".  When prompted, enter the username and password for 'SomeoneElse'.

In Lightning, you now see events from both users' remote calendars.  Perfect.

In signons.txt, you now see:

dav.messagingengine.com:443 (dav.messagingengine.com)
\=username=\
<encrypted>
*\=password=\
<encrypted>
.
dav.messagingengine.com:443 (dav.messagingengine.com)
\=username=\
<encrypted>
*\=password=\
<encrypted>
.

6) Here's the problem.  Restart Thunderbird and you're prompted with, "Select a username to be entered on this form."  The choices are:

user1@fastmail.fm
user2@fastmail.fm

I choose user1 and click OK.  Now I get a second dialog with user1's username and password pre-filled, and the following checkbox is checked: "Use Password Manager to remember these values".  I click OK and then see user1's events on the calendar, but not user2's events.

Every time that I restart Thunderbird, I have to follow the steps in (6).  I can choose to see either user1's events or user2's events, but never both at the same time.  All of the necessary usernames and passwords are saved in Password Manager, but apparently only one set can be used at a time.  It seems that Password Manager works on a per-domain basis, and ignores everything else in URLs.

Ideally, I would not see *any* prompts for usernames or passwords when I restart Thunderbird, and Lightning would automatically load all remote calendars for all users.
Whiteboard: [qa discussion needed]
for qa-discussion: 
I have been thinking about this (sorry Pete: have been thinking for quite some time). This is a valid user-case which should be solved if we want to provide (more failsafe) support for sharing calendars. If we use external webdav-providers over which users have no control (pete says messagingengine.com, I know icalx and there are numerous others) people won't  be able to set the permissions for different users (hence they can't use one username for accessing calendars for multiple users). 

I have a remote webdav for which I set the url to http://user1@domain/cal.ics. After lightning (2007041205) asks me for my password I can see the calendar and the password is stored as "domain (realm)". Everytime I restart I'm asked again for the username and password (both are empty while the password-manager shows the correct username and password). If after a restart I login with the credentials of user2 which has the same rights as user1 strangely enough there's no problem anymore after restarting. I would expect the same behaviour as with user1 which could be caused by checking "user1@domain" against "domain" in the password-manager but apparantly something else is going on? 

All problems with realms etc could be avoided by including the username* in the url for password-manager (and don't add the password if this is included in the url). The only disadvantages I can think of are that we use multiple connections to one server where we -might- be able to use just one and that the credentials for the server have to be entered and stored in the password-manager once for each account. 

other providers:
The same sort of thing applies to caldav-provider if I read bug 371753 and
http://forums.mozillazine.org/viewtopic.php?p=2848310 
correctly. I don't know wether there are external caldav-providers already? gdata-provider names the server the same as the username, so no problem with that (no multiple usernames for one server and/or realm). ftp does this correctly already (including username in url). I don't know exactly how wcap handles this (I have no wcap-server).

* let me refer to bug 273478 comment #3 where it's usefull to ask for a username when creating the calendar. We could do that also with webdav and caldav, gdata does this already.
Status: UNCONFIRMED → NEW
Ever confirmed: true
added bbrowning for caldav-implications.
(In reply to comment #12)
> All problems with realms etc could be avoided by including the username*
> in the url for password-manager
> [...]
> ftp does this correctly already (including username in url).

POP3 and SMTP accounts also include the username in the URLs.  So I agree and would like calendar accounts to do this too.


> The only disadvantages I can think of are that we use multiple
> connections to one server where we -might- be able to use just one and
> that the credentials for the server have to be entered and stored in the
> password-manager once for each account.

I don't think that this disadvantage would apply to most people.  In my case, there are two independent accounts (owned by two different people) on the same webdav server.
I should have also said that I'm using SSL (https) which I think requires two separate connections in order for me to subscribe to the calendars of both users.
I guess I don't really see caldav implications here, other than in cases like bug 371753, where the user has IMHO untoward expectations of HTTP Basic (RFC 2617) authentication. The caldav servers I'm aware of - to the extent that they yet address this kind of thing at all - expect client applications to use a single name/pass for each realm@host, with server-side access controls allowing (or disallowing) access by one principal to another principal's calendar(s). That's the pattern I'm familiar with for RFC2617-compliant applications, so I'm a little skeptical that there's a bug here other than the odd interaction between the password manager and URIs with embedded usernames. There's perhaps an enhancement request here, for the password manager to allow storage of auth information for URIs instead of authrealms. But my take would be that what's needed here is server-side, either by putting the different calendars in different realms or by providing ACLs (or somesuch) to do the authorization piece as needed.
Keywords: relnote
Whiteboard: [qa discussion needed]
Just a post to confirm that I have experienced a similar problem as recent as the 5/02/07 nightly build of pre-0.5 for Windows.  In my case, I was attempting to use five calendars on the same server with the same credentials sent via http.

Example:
http://myuser:mypass@mycal.com/cal/calname.ics
http://myuser:mypass@mycal.com/cal/calname2.ics
http://myuser:mypass@mycal.com/cal/calname3.ics
http://myuser:mypass@mycal.com/cal/calname4.ics
http://myuser:mypass@mycal.com/cal/calname5.ics

The username/password was identical for each/all of them.  Sunbird has quirky behavior with this.  Some of them will work fine, and some will pop up the window asking for the password.  Even if the username/password is saved, it will still ask when doing a manual calendar reload or on starting the program.  It is almost random, however, because if I unsubscribe to a calendar and then add a new subscription, it will pop up the password thing on another one.

I should add, however, that in this same version, I have tested the url's without sending the user/pass in the url, but using Sunbird's password remember feature.  It is working on two machines subscribed to six calendars each on the same server with the same user credentials.

I had tried to use the user/pwd in the http with previous builds b/c Sunbird wouldn't remember the user/pass information consistently.  That seems to be resolved now.  It might be best to put this in the doc's somewhere as a known issue with sufficient work-arounds.  It's probably safer for sunbird to store the passwords anyway, than they be in the url.

I also posted this info at bug: 371753

Steve
And More Testing:

Using Lightning 0.5, and a Cosmos CalDev Server.

The URLS that Cosmos offers are in the form : 

http://cal.jara23.co.uk:8090/cosmo/dav/collection/29bce870-ca94-4e11-869a-0a6b7dde46b2

With the numbers after /collection/ changing for each user. As usernames and passwords are only remembered based on "http://Cal.jara23.co.uk:8090", shared calenders are impossible. Also, putting "http://user1:password1@cal.jara23.co.uk:8090" only allows for this calendar to show, another calender *without* the user:password, but has the details saved in password manager is not shown.

Shared calenders here are being used with 1 as a personal calendar, and one as a shared calender for meetings. 

Thanks

SK
Note: The above is a problem on Linux as well. 
Hi all,

This is my first post on bugzilla.

I am having the same problem with Sunbird 0.7 Win XP and Sunbird 0.7 Mac OS 10.4

Thanks,

Stuart.

Folks, Two "Sunbird" calenders show up in locations: moz-profile-calendar://?id=2 and moz-profile-calendar://?id=2 on a USB (Cruzer micro 1.0GB) thumb drive (TD) supported by a Del XP laptop.  I cannot, however, find (via search) where these files are stored on the TD (they do not appear in profiles). When I move this TD to another Windows XP PC (Toshiba)machine "Sunbird" opens to an entirely new calendar without showing the two existing calendars.  When I save a "test" calendar in this second (Toshiba XP)location I am undable to find this "test" calendar when the thumb drive is back in the "Dell XP" How do I make this very fine product really portable between two XP platforms?  Thanks
Gary, this belongs in the forum (http://forums.mozillazine.org/viewforum.php?f=46) and certainly not in this bug... moz-profile-calendar means the data is stored in the storage.sdb file and a single profile can only have a single storage.sdb.
Based on my use case, this fix is indeed needed.  I'm accessing a davical server where the calendar URLs are supposed to be (and are) of the form:
https://calendar.mydomain.com/caldav.php/username/calendarname/

Since each member of my team's calendar plus the "group user's" calendar differ only in the "username" part of the URL, and have different passwords, there seems to be no way to access even 2 calendars at a time (our respective personal ones plus the group one).  Let alone share or see each other's personal calendars.

I've tried many combinations of the URL as its "supposed" to be plus combinations of putting the https://username@calendar.mydomain.com.... and it may bring in the events of calendar, but if I add a second calendar (though the events may show up initially) then as soon as I click to a different week or month, the events of the first calendar (or both) disappear.
(In reply to comment #24)
> Based on my use case, this fix is indeed needed.  I'm accessing a davical
> server where the calendar URLs are supposed to be (and are) of the form:
> https://calendar.mydomain.com/caldav.php/username/calendarname/
> 

DAViCal provides CalDAV calendars, not WebDAV/ICS which is the subject of this bug. You probably meant to post in bug 388578. But to save you the trouble ... the way to handle this issue on HTTP-based protocols like WebDAV or CalDAV is not to attempt to log into the same realm simultaneously with multiple credentials, it is to authenticate with a single set of credentials and configure the server to allow (and disallow) access appropriately using those credentials. I've not done this with DAViCal, but there's a page at http://rscds.sourceforge.net/administration.php that talks about this. I think one of the examples there is on point to what you are trying to accomplish.
OS: Windows 2000 → All
Hardware: PC → All
Summary: can't load several calendars with different passwords on same server → can't load several calendars with different passwords on same server/realm
i experience problems with davical, with multiple calendar, so if i add http://davical.server/caldav.php/user1/home and http://davical.server/caldav.php/user2/home, it asks for user pasword for only one of them, even if i store the password into password manager, or i attempt to imput them from keyboard. It seem that sunbird try to use the first part of the url, only the server name, not the complete url, so it try to authenticate the different calendars with the same user.
FYI, this problem still exists in thunderbird 3b2 and today's lightning nightly.

The workaround of adding the username into the URL does not appear to work.

The greatest pain point of this appears to be Google Calendar, given the number of calendars out there.  Given two user names (user1 and user2), to access these calendars via caldav (protocol is mostly irrelevant) you would user two calendar URLs like this:
https://www.google.com/calendar/dav/user1@gmail.com/events
https://www.google.com/calendar/dav/user2@gmail.com/events

Both of these URLs report the same realm.  And thus, even though there are clearly two users involved, only one password gets saved and the other URLs is unusable.
I think I have the same desired behavior/UI in mind as every other user complaining about this bug, and this is it:

 * I describe remote calendars to lightning as triples of:
    a) user-visible identifier (the name that shows up in Lightning UI)
    b) a URL for the resource
    c) a username/id for authentication
 * When connecting to a calendar, Lightning asks me for the one remaining piece of missing information, a password.
 * That's it.

I, the user of a calendar, do not care about what realm id happens to be returned by the remoter server over whatever wire protocol happens to be used to get to the calendar data.  I just care that for *this* calendar, I am identified to the server with *this* id --- and for *that* calendar, I am identified with *that* id.  The two servers might be the same; the two calendar URL's might even be the same.

I also don't want Lightning to pop up a dialog box that asks for both a password *and* a username.  For any calendar that I have configured, I knew the intended authentication username when I configured it, and it's not going to change, so Lightning should never have to ask me for it.  (I knew the password, too, but I might prefer to type that in for every new connection and not have it cached somewhere.)

In other words, I want Lightning to treat calendars the same way that Thunderbird treats email.  I want to set up a named account that points to some folders on some server under the auspices of some identity.  And I want to be able to do that multiple times, potentially using different identities for the same server and same folders.  Maybe I want this because I'm ignorant of how ACL's work, or maybe the calendar service I am forced to use doesn't support ACL's... or maybe I know all about ACL's and I want to *test* them without setting up multiple independent thunderbird/lightning profiles.  Nothing about this functionality prevents me from using ACL's properly to access Boss B's calendar under the guise of Assistant A --- the use of ACL's to relate resources to authentication id's is orthogonal to this bug.

No, I don't care if the underlying calendar resource is served via an HTTP-based protocol, or FTP, or telnet, or gopher.  CalDAV vs WebDAV/ICS?  I don't care --- I still want to be able to access the same server using multiple identities.  Just like I can freely "ssh user1@example.com" and "ssh user2@example.com" without logging in to my laptop twice.  If I happen to have two or more sets of credentials for accessing the same server/calendar/resource, I want to be able to use them all.

I really don't understand how this can issue can linger on for six years without being acknowledged as a plain old flaw in the interface.  Is there something in the fundamental Lightning architecture that makes this dicey to fix?
I started looking at the code. Wow, it's a lot of code!
It looks like the linking of a username/passord with the prepath of the calendar is done outside the calendar, maybe in the password manager itself?
Can anybody give me a hint here?

Shai
Core calendar team:  Could we move on to discussing the actual design of a fix?
I also started looking at the code a couple of weeks ago.  (After writing that long bit of ventilation, I figure I should try to step up and help in some material way.)

What I understood from that is that CalDAV calendar support in Lightning basically works by preparing an HTTP URI for a request, and submitting that to the remote server via the underlying HTTP transfer infrastructure built into the mozilla libraries.  So, it inherits the same functionality and the same foibles that one has to endure for HTTP requests with Basic Authentication in Firefox.  The password dialog box that pops up is provided by deep library support; Lightning proper has nothing to do with it.

Does the HTTP library provide a hook which would allow Lightning to wedge itself in between the HTTP authentication protocol handling and the default password lookup/dialog?  If Lightning could do its own lookup (e.g. provide its own dialog), or if it could at least customize the parameters (e.g. realm) handed to the password-manager module, the desired functionality should be possible in principle.  If not, I get the feeling someone would need to add such a hook to mozilla, and that would probably involve a lot more work and face a lot more resistance from upstream.

That's as far as I got on my own; if someone with deeper knowledge of how all this works could point me in the right direction, I'd be happy to take another deep breath and dive in again.
From  my stab at trying to fix this, I agree with what Matt found out, but I want to add that the "Google CALDAV" realm is reported to the underlying HTTP transfer infrastructure by the google server, so we would have to somehow override this.
I too do not have deeper knowledge than that.
Is there a workaround ?

I absolutely NEED to change my user; what is the profile file I should remove, or edit to WA this bug ? even if this removes all my other remote calendars ... as long as it does NOT alter other non cal things (mail, news ...)
I just want to emphasize my vote for fixing this -- it is what is blocking a user from subscribing to multiple Google calendars with Lightning, which seems like a very common use-case scenario.  The only other alternative to CalDav is the GDATA_provder add-on, which also has a fatal flaw in that it causes Google to send out unsolicited invitations (https://wiki.mozilla.org/Calendar:GDATA_Provider, sec. 4.6)

So right now (after spending several hours trying to find a solution) I am unaware of any way to get multiple syncing Google Calendars in Lightning.
(In reply to comment #39)
> I am
> unaware of any way to get multiple syncing Google Calendars in Lightning.

Turn off the Master Password (and use a password to lock your OS user profile).
There *is* a work around, at least for Google.  It appears that all of Google's calendars are available via www.google.com AND calendar.google.com.  Entering different calendars using the different hostnames will make it work.  I'm sure other hostnames might be available if one looked hard enough.

One must remember that Thunderbird is actually implementing the spec here: they are keying usernames/passwords to a hostname/resource pair.  This is the *correct* behavior.  The incorrect behavior is that Google uses the same resource for all its calendars, when (at the very least) it should use a separate resource for each "apps for your domain" domain.  In short, the bug is Google's not Thunderbird's.

That being said, Thunderbird may want to allow behavior that is different than what the relevant RFC states in order to provide a better user experience with Google and other major hosts who don't implement the RFC in the best way.
(In reply to comment #41)
> One must remember that Thunderbird is actually implementing the spec here: they
> are keying usernames/passwords to a hostname/resource pair.  This is the
> *correct* behavior.  The incorrect behavior is that Google uses the same
> resource for all its calendars, when (at the very least) it should use a
> separate resource for each "apps for your domain" domain.  In short, the bug is
> Google's not Thunderbird's.

This is not correct.  The spec does not talk at all about dynamic content and signing in as multiple users for the same realm.

"The realm value [...] defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database."

The ream stays the same, but in our case Thunderbird has to manage multiple sets of login/password sets for the same realm.

This issue does not only apply to gmail, but to any other service that uses HTTP authentication for data exchange.
(In reply to comment #42)
> "The realm value [...] defines the protection space. These realms allow the
> protected resources on a server to be partitioned into a set of protection
> spaces, each with its own authentication scheme and/or authorization database."
Right, so each Realm should have its own authentication scheme. Since Google provides the same realm for every calendar, they are still doing something wrong. This does seem to be common practice though, so lets put that aside.

I think we should do something about it on the client side. Its just a question of what and how. Changing the realm sounds like a possible hack, but we'll need to dig into the mozilla networking code to see what and where we can change things.
(In reply to comment #41)
> One must remember that Thunderbird is actually implementing the spec here: they
> are keying usernames/passwords to a hostname/resource pair.  This is the
> *correct* behavior.  The incorrect behavior is that Google uses the same
> resource for all its calendars, when (at the very least) it should use a
> separate resource for each "apps for your domain" domain.  In short, the bug is
> Google's not Thunderbird's.
> 
> That being said, Thunderbird may want to allow behavior that is different than
> what the relevant RFC states in order to provide a better user experience with
> Google and other major hosts who don't implement the RFC in the best way.

Where in which RFC is this behavior specified?

My reading of the RFC's is that CalDAV can use HTTP Basic Authentication,
and RFC2617 says that in HTTP Basic Authentication the server provides the
client with a 'realm' string in its challenge.  Most of the spec revolves
around what the server should do:

  * [Section 1.2] "The realm value (case-sensitive), in combination
    with the canonical root URL (the absoluteURI for the server whose
    abs_path is empty; see section 5.1.2 of [2]) of the server being
    accessed, defines the protection space."

  * [Section 2] "The realm value should be considered an opaque string
    which can only be compared for equality with other realms on that
    server."

  * [Section 2] "The server will service the request only if it can
   validate the user-ID and password for the protection space of the
   Request-URI."

It doesn't say that userid/password is keyed to hostname/resource; it says
it's keyed to canonical-root-url/realm.  Sure, realm == resource, but
canonical-root-url != hostname.  In fact, I have the feeling that there's
a misprint in Section 1.2: "server being accessed" should have been
"service being accessed", because the intent appears to be that the key
is the root-path of the resource being accessed (where the resource is
a subtree of the path-space of the server).

Anyhow, this is all about what the server should do.  The last paragraph
of Section 2 does say something about what the client should do:

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.

So, if a client has already authenticated to "http://example.com/a/b", then
it should assume that "http://example.com/a/b/c/d" is covered by the same
bits.  However, the RFC does not say what the client should do with
"http://example.com/a" or "http://example.com/a/q".

The RFC says nothing about how the client should present any of this to
the user either.  Given all the above, it seems that the problem is that
Thunderbird is implementing an interface that goes *beyond* the behavior
specified in the RFC, and does so in a way that is annoying and 
counter-intuitive to the user.  (Firefox has the same user interface,
but the behavior is defective in a different way since the interaction
with a "website" is very different from the interaction with a CalDAV
calendar service.)

----

Once again, I reiterate my offer:  if some one points me in the right 
direction in the mozilla codebase and gives me some coaching, I'd be
happy to try to do some work on this.  (Reading some RFC's is one thing,
trying to understand how that mass of code works is another.)
(In reply to comment #44)
> (In reply to comment #41)
> > One must remember that Thunderbird is actually implementing the spec here: they
> > are keying usernames/passwords to a hostname/resource pair.  This is the
> > *correct* behavior.  The incorrect behavior is that Google uses the same
> > resource for all its calendars, when (at the very least) it should use a
> > separate resource for each "apps for your domain" domain.  In short, the bug is
> > Google's not Thunderbird's.
> > 
> > That being said, Thunderbird may want to allow behavior that is different than
> > what the relevant RFC states in order to provide a better user experience with
> > Google and other major hosts who don't implement the RFC in the best way.
> 
> Where in which RFC is this behavior specified?
> 
> My reading of the RFC's is that CalDAV can use HTTP Basic Authentication,
> and RFC2617 says that in HTTP Basic Authentication the server provides the
> client with a 'realm' string in its challenge.  Most of the spec revolves
> around what the server should do:
> 
>   * [Section 1.2] "The realm value (case-sensitive), in combination
>     with the canonical root URL (the absoluteURI for the server whose
>     abs_path is empty; see section 5.1.2 of [2]) of the server being
>     accessed, defines the protection space."
...
> It doesn't say that userid/password is keyed to hostname/resource; it says
> it's keyed to canonical-root-url/realm.  Sure, realm == resource, but
> canonical-root-url != hostname.  In fact, I have the feeling that there's
> a misprint in Section 1.2: "server being accessed" should have been
> "service being accessed", because the intent appears to be that the key
> is the root-path of the resource being accessed (where the resource is
> a subtree of the path-space of the server).

After some sleep and food and review of what I wrote, I apologize for
my own misreading of the spec.  The "protection space" is more or less
keyed to (protocol, hostname, port, realm), and the resource path is
not included.
 
>    A client SHOULD assume that all paths at or deeper than the depth of
>    the last symbolic element in the path field of the Request-URI also
>    are within the protection space specified by the Basic realm value of
>    the current challenge. A client MAY preemptively send the
>    corresponding Authorization header with requests for resources in
>    that space without receipt of another challenge from the server.

And that paragraph says that if a client has credentials that work for 
"http://example.com/a/b" then it should assume that the same credentials
will work for "http://example.com/a/b/c".  However, it doesn't say that
they *will* work --- I guess it is just suggested behavior for the server
and its layout of protection spaces, but not a rule.

I stand by the gist of the rest of what I said, though:  the spec mandates
certain behaviors for the server, but does not say what the client should do,
nor does it ascribe any particular semantics to "realm".  From the client's
point of view, the realm is a hint as to how to supply credentials that will
be accepted.

The spec says nothing about which credentials (userid/password pair) a client
should provide in response to a server's challenge.  So, if a client wants to 
respond to the same realm with different credentials, that's fine.  If a client
wants to provide different credentials for independent requests to the same URL,
that is also fine.  (This may not adhere to the "spirit" of the spec, but
neither does using it for CalDAV authentication.)

I think the preferred interface for Lightning with regards to all this is the
same one used with IMAP accounts:
 * User creates a "calendar account", by specifying 
    * URL
    * userid
    * local label
 * The pair (URL, userid) is a unique key for the account.
 * When accessing that account, lightning prompts for a password for that account (identified in the UI dialog by the local label), which might then be cached somewhere,  etc.
 * Multiple calendar accounts can have the same URL, or same userid, but not both.
 * The realm presented by the server is irrelevant (as lightning already knows which credentials the user wants it to use).
(In reply to comment #40)
> (In reply to comment #39)
> > I am
> > unaware of any way to get multiple syncing Google Calendars in Lightning.
> 
> Turn off the Master Password (and use a password to lock your OS user profile).

I never had it on.
(In reply to comment #41)
> There *is* a work around, at least for Google.  It appears that all of Google's
> calendars are available via www.google.com AND calendar.google.com.  Entering
> different calendars using the different hostnames will make it work.  I'm sure
> other hostnames might be available if one looked hard enough.

Worked for me. Any one have more "names" ?
Possibly www3.l.google.com, although it redirects in a browser.
(In reply to comment #48)
> Possibly www3.l.google.com, although it redirects in a browser.

Hmmm ... did not test yet, but I give more ideas to be tested:
- all the youtube space domaine
- all app specific sub domains (gmail, picassa, documents ... )
- all IPv6 specific names
- all machines, by fixed IP using v4 and v6 (IIRC syntax is http://[f00::1]/bar ).

For those who have time to loose, this could lead to a >20 name list. Should be enough for *most* people who need to WE this bug :)
This is entirely NOT useful.  There are many other consumers other than gmail.  So instead of diluting this bug report with random google hostnames, please focus on the problem at hand:  we need a way to directly specify user and password for a given request.  nsIJSXMLHttpRequest.open() takes a login and password, but it seems to be ignored.
I don't have technical backend to help on this; but I can still help other users.

> we need a way to directly specify user and password for a given request.

I think there is no clean way to do this. Because ... if we do path-level specific stuff, we will have to do server/domain specific patches in the end. Google has it's own way to interpreet the RFC. Other services will do it a different way.

So, hardcoding an exception for Google is not acceptable.

Doing a per server configuration seem to be a mid-stage solution. But, as the GUI front-head is per-user-account oriented, having a per server thing in the backend is really not a good idea. A per-server configuration chould be done in the preference settings. To allow one server to assume foobar.com/a/b to be different from foobar.com/a/c, and still allow foobar.net/a differ from foobar.net/d . A two columns configuration pannel, like for password: left=server, right = path length to be "user specific", don't ask password under below this lenght, ask different username if higher.

This could work, but, i think it's not clean enough, and that the dev team will reject my idea.

IMHO, the root problem is that the password manager, and the account manager are orthogonal. In THIS case, we almost need a per account password, what is impossible due to the design of the Mozilla suite. We need to cut the orthogonality.

Why does this problem NOT happen with Imap ? If calendars are specific use case, and cal passwords are managed a different way than Imap, then, my idea is not so stupid: we could write "password retention rules" ... that would be cal specific ... and, cal specific options in the Preference menu. Thus, my idea to add a new Cal entry in the pref menu. To allow, and custom Cal specific password retention policies.

In fact, the root problem of the bug is that, servers don't segment "user profile" at the same depth. So, we need to let the "user" custom this in a way or an other. Can not be per account; so, NOT in the account manager.

My 2c.
No, the problem is not in the password manager, but in the underlying mozilla engine.  It also doesn't work if you don't use the password manager.
The world would be much easier if someone would feel responsible for this bug. 6(!) years... come on, guys. This is a major issue.

So, if it's not possible to assign this issue to a member of the Lightning team or fix the issue in any other way because of stupid RFC discussions: Would you (the Lightning team) please make it possible to show and manage CalDAV ACLs from within Lightning? Logging into a server or web interface of, let's say DaviCAL, every time you want to change an ACL for your calendar is no option in a professional environment. Besides that, not every CalDAV server supports ACLs.
How is that in ANY way related to the bug?

Also I believe this is a mozilla issue, and not a lightning issue.  Maybe we should change the product?
This is related to the bug in EVERY way. Everybody who's able to count to three can see that. There is no need for sarcastic questions. At most there is a need for changing some kind of thinking. It is no solution to point your finger at others if something went wrong. As a developer I have to ask myself, what can _I_ do myself to solve the issue. This discussion leads into a dead end street. 50+ comments in over 6 years with only "blah blah" (except what Matt wrote). That's a shame IMO and reminds me of public authority. Changing the product is no solution either. Making a good product better is a solution.
How do other softwares do ?

***

What's wrong with this ?
- in the user pref pannel, create a new tab with ...
- a per domain policy selector
- for each domain, the user can choose the level/depth for which a login/password is valid; =1 means a login is valid for all domain.com; =3 means it's for domain.com/a/b and so on. With special value 0 for, one password per URL. 
- with a default value, or a default setting.

It would not be the first orthogonal conf and profile management in TB: see how SMTPs are managed: for each mail account, you can either choose to have a specific SMTP, create a new one, share one with other accounts, or, use the "TB default one" that is set in an other menu. The same way we have a "per email SMTP policy", i propose a "per domain password policy" for Cals. That way, users can adjust the valid depth for each server.
Oh what?  Maybe we are talking about different things here.

I think this is an issue with the mozilla backend.  If there was a way for a provider to specify which user/password to use exactly for a given request, everything would be fine.  Actually, the XmlHttpRequest.open accepts user and password parameters, but they don't override a previous setting once the first connection has been made.

So, changing the product will make this visible to those parties that can actually change the backend.  Lightning is simply a consumer of the existing infrastructure.

== OT ==
How is changing CalDAV ACLs related to user/password caching in mozilla?
Mario, Simon was merely noting that your comment doesn't match with the bugzilla etiquette, see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. I'm sure he did not mean to step on your toes.

I understand your anger with this bug not being fixed, but given the vast amount of other bugs that need fixing, we just haven't gotten around to finding a workaround or solution for this. See especially section 1.2 in the etiquette.

As you've rightly noted, it doesn't make sense to add comments unrelated to this bug, otherwise there will be another 50+ comments with only "blah blah". If you would like support for ACLs, please find the bug to support CalDAV ACLs instead and vote on it. Aside from that, implementing CalDAV ACLs will not fix this bug, since the actual problem lies in the mozilla network code and even with ACLs implemented, this bug will still cause problems.

Moving this bug to Core/Network will likely cause it to be WONTFIXed, since from their perspective they are following the spec. I fear we'll have to either find a calendar workaround, or provide a core patch that makes them happy.
But it has already been shown that they are would be wrong in the conclusion that they are correctly following the spec. In this case they are not and they should fix that.
I still think this bug should be moved to core/network, if only to get some more input on how to address this problem.
Writing comments when you are in a bad mood is not a good idea. Sorry for ranting.

I threw ACLs in, because using them is a good idea basically and they would make it possible to omit using multiple accounts at the same realm. If only there were a nice way to administrate them we've had probably no discussion about this bug. Reading discussions about how to interpred RFCs and being helpless is very frustrating and not understandable for an end user.

I abolutely understand that it is not a good idea to develop against an RFC. Unfortunately you can't constrain a developer to code the "right" way, you can only react and code dirty hacks. But: do one really want a product that - in public opinions - simply does not work correctly? So please, let's work out this issue, even it's a dirty hack.

Philipp, I see there's a lot of things to do and simply having no solution is a good argument. But why is this bug assigned to "Nobody"? In my opinion you should assign a bug first, then realize that you've got no solution. A few users wrote that they had a look into the code and that they like to contribute, but no answer was given. So, if one is not able to fix it (and whatever the reason is), why don't they accept from people that a willing to work on it?

I'm with you, Simon. This bug should be moved/copied to core/network. If nothing happens within 6 years, nothing would happen within 60 years. Let's see if a discussion at core/network comes to a positive conclusion.
This bug must not be moved to a different product. It's way too long to read. If anything, a new bug should be created. Especially comment 44 and comment 45 are relevant.
But fixing the path issue does not fix the problem here for all cases. There might be servers that use the same URL for all users.
(Lightning developers can change the backend. And there are ways to change network data from outside code. So moving the bug is not needed to get it fixed)

The password manager is not relevant here. Password are stored in memory for the session, even without using the password manager.

A calendar-specific trick could be to change the realm of the http response. A problem with that is that any network observers only see the request and the URL. They have no way to get the calendar and thus the user that is associated with this request.
What if we send a X-Lightning header so that we can match it back to the calendar?  That'd be a massive hack, but if it works...
Actually, I'm a bit lost at what the actual bug here is. Is it:

a)
When using the urls:
https://user1@www.google.com/calendar/dav/user1@gmail.com/events
https://user2@www.google.com/calendar/dav/user2@gmail.com/events
does not work (both give the same events, second does not work at al)

b)
storing passwords between sessions (using the password manager) for above url's does not work, only one password is saved

c)
something else.

with regard to a): there is code to make that work. If it does not work, there is a bug in core code. code is at:
http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#1230

with regard to b): changing the realm might not work, because you need to send the password at the request, and the realm gets send at the reply. So the mapping of url to realm must be changed. I didn't yet find a way to plug into that.
A possible solution would be to store the username-part of the url in the password-manager as the ftp-provider does. That way, every account has it's own unique URL (with the same realm but that doesn't matter).
Just to keep things from being to Google-centric.  We've been playing with a Davical server.  URLs for the Calendar look like:

http://calserver.our.domain.edu/bob/home
http://calserver.our.domain.edu/morgan/home

Two different people, two different passwords to access, Lightning will only work for one of them at any given time.

The user community expects the kind of behavior exhibited by Apple's iCal product, you set up both calendars, they have a different user name and password associated with each calendar, and it WORKS.
from 2004-06-18 to 2011-05-26 .... 7 years and this bug is still here!!!

which of the following is the cause:
1) Can't decide whose fault it is (mozilla's or the rest of the world) according to an RFC meant for something unrelated (webservers)
2) Can't find anyone who can fix it
3) Can't find anyone who can AND wants to fix it

what a shame
Shut up and wait for the surprise birthday party !
All,

As a note I'm still experiencing this issue on Lightning 1.0b2 with Zimbra.  In fact, using lightning with more than one account on the same Zimbra server would seem to be entirely broken.

If I add a second calendar, the first calendar breaks, and can only be fixed by deleting and recreating it.  At which point the second calendar breaks.
Attached patch Fix - v1 β€” β€” Splinter Review 
Happy birthday to you, happy birthday to you;
Happy birthday dear bug, happy birthday to you!
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #549601 - Flags: review?(mschroeder)
Comment on attachment 549601 [details] [diff] [review]
Fix - v1

Review of attachment 549601 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable.  Patch not tested.
Oh look, this bug brought its friend, bug 662235! They like each other so much they want to be closed together!
Philipp,

Oh, you shouldn't have!

Wait, no, you should have.

Is there a nightly I can grab to test this?  I can make sure the fix works with Zimbra servers, at least.
Comment on attachment 549601 [details] [diff] [review]
Fix - v1

Looks good code-wise, but haven't tested it yet. r=mschroeder
Attachment #549601 - Flags: review?(mschroeder) → review+
I *NEED* to reach a 3rd time google (after www.google.com and calendar.google.com ) . www3.l did not work. calendar.doublehp.org also failed (I defined it to be a DNS cname to calendar.google.com ). Why would the two last names fail ?
(In reply to comment #78)
> failed (I defined it to be a DNS cname to calendar.google.com ). Why would
> the two last names fail ?
Likely because the http request is setting a Host: header that google doesn't associate with the calendar service?

plop, I'm going to check in the patch today, if you wait a day maybe you could test the nightly builds to see if it works for you?
Oh did I mention this will cause previously saved passwords to get "lost"  (since the realm changed). I think thats something we can live with, the migration would be quite a pain!


Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/736a510d807e>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
at last ? \o/ in which release will this be available ? which version ? (I am not asking for a date :D )

Yeah, password loss is acceptable *once*. Migration would mean that all future versions would store the code for old API to be able to read it ... have bugs and so on ...
Philipp,

Given that the old code sometimes loses passwords anyway, that is completely acceptable.
Wait a day and get the nightly build from:

http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/

It requires a Thunderbird 8.0a1 nightly build
Hmm we might want to do some more steps here w.r.t password saving. Some situations where entering a new password is required:

* You change the calendar name (the realm changes, new password prompt on restart)
* Isn't it annoying when you have a lot of calendars on the server that actually do have the same password? You'd have to enter the password for each one.
* What about digest auth? IIRC they use the realm name as part of the auth challenge?
Also, there is an error I overlooked, 

Error: calendar is null
Source File: resource://calendar/modules/calUtils.jsm -> file:///home/kewisch/mozilla/comm-central/obj-x86_64-unknown-linux-gnu/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Line: 276

reopening. Given this method is a bit error prone, we might consider querying a default-off hidden preference so this doesn't disrupt users with one password per server.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> Isn't it annoying when you have a lot of calendars on the server that
actually do have the same password? You'd have to enter the password for each
one.

several calendars on the same server can have different usernames; and different usernames hardly have the same password ...
(In reply to plop from comment #86)
> > Isn't it annoying when you have a lot of calendars on the server that
> > actually do have the same password? You'd have to enter the password for each
> > one.
> 
> several calendars on the same server can have different usernames; and
> different usernames hardly have the same password ...

I actually meant same user and password, i.e. as required before. Lets say you have a caldav server and add 10 of your own calendars from it. You'd have to enter the same user/password combo for each one.
That's the inverse this bug is trying to address... Maybe we should open a new bug for that? :)
Yes, I know. I'd rather try to find a solution that works for both cases. This might even go down to a custom login dialog that lets you select "Use these credentials for all calendars on this server" (in a different bug of course) but in light of releasing 1.0 asap I'd rather not do this now. A preference should do it for now and wouldn't go outside the scope of this bug.
Accessing two Google calendars (same hostname for both) still affects me on ThunderBird 6.0 and Ligtnin 1.0b5 (Ubuntu Oneiric packages).
Iam going to look for a PPA with last version if it's better.
I doubt there will be a ppa, but you can surely download the official builds from ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-miramar (or maybe latest-comm-aurora)
This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.
Target Milestone: Trunk → 1.0b6
Needs to be taken care of asap, especially since it causes an exception sometimes.
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
Please define ASAP.
ASAP => ASAIHT (As soon as I have time ;-)

I need to fix the exception being thrown for channels that don't implement calICalendar in its callbacks, and pref-off this feature so that there is no mass-invalidation of passwords.
Attached patch Pref off - v1 β€” β€” Splinter Review 
This patch takes care of fixing the exception and also turning the feature off per default via a preference. I wouldn't want to burden everyone with entering the password again and again for each calendar after an upgrade.

If you are using this patch and would like to have it on again, please set "calendar.network.multirealm" to true in the advanced config editor.

I'd appreciate speedy review (from anyone) so we can throw this in the nightly builds.
Attachment #560126 - Flags: review?(matthew.mecca)
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]
Thank you for your patch. Unfortunately I'm not able to test it ATM. I promise I'll try ASAP.
Philipp, do you think it'll work on those thunderbirds builds? https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
The additional patch is not reviewed yet, so it won't be available in those repositories. Also I don't see a lightning build in that ppa repo.
Comment on attachment 560126 [details] [diff] [review]
Pref off - v1

Untested, but codewise r=mmecca
Attachment #560126 - Flags: review?(matthew.mecca) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/dc0820370836>
-> FIXED
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Target Milestone: 1.0b7 → Trunk
Backported to comm-aurora <http://hg.mozilla.org/releases/comm-aurora/rev/5827d8225ac4>
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact]
Target Milestone: Trunk → 1.0b8
Backported to comm-beta <http://hg.mozilla.org/releases/comm-beta/rev/2aed8aff80c9>
Target Milestone: 1.0b8 → 1.0b7
I'm testing this now.  However, my realm is not getting rewritten using the calendar name so multiple calendars still aren't working for me.  How should I go about debugging this?
Hello, FYI, I still can't open calendars for two different users on the same server.
>> calendar is momentarily not available

WinXP, Thunderbird 8 + Lightning 1.0, Zimbra 7

https://mail.mydom.be/dav/self@mydom.be/calendar
https://mail.mydom.be/dav/info@mydom.be/calendar

workaround works if I change hostname, e.g.
https://www.mydom.be/dav/info@mydom.be/calendar


I can provide 2 tests accounts to developper on request.
tubaman, Skx, can you please file a new bug on your persisting problems as this report has already been closed and more than 100 comments.
Before I try to get someone to reopen this BUG - can anybody tell me WHAT I am supposed to do NOT to encounter this BUG using caldav - I couldn't find any setting regarding this and find this not working with Lightning 1.2.1 - I think https://bugzilla.mozilla.org/show_bug.cgi?id=707138#c3 is addressing the same thing...! I am afraid you guys need to get back to work...!
;-)
This doesn't work with the release version of Lightning 1.3 (and Thunderbird 11.0.1).

I have two separate e-mail accounts within my Google Apps account. When I add the calendar from the second account, all I get is the yellow triangle. I tried deleting the password entry for the first account in Thunderbird's "Stored Passwords" dialog and restarted Thunderbird. Still no joy!
(In reply to Peter Lairo from comment #109)
> This doesn't work with the release version of Lightning 1.3 (and Thunderbird
> 11.0.1).

Peter, does setting "calendar.network.multirealm" to true help? (see comment#96)
(In reply to Martin SchrΓΆder [:mschroeder] from comment #110)
> Peter, does setting "calendar.network.multirealm" to true help? (see
> comment#96)

I'm sorry, I just don't have the time to test this.

Comment #96 says it turned the feature OFF. I assume for a reason. And:
"If you are using this *patch* and would like to have it on again, please set "calendar.network.multirealm" to true in the advanced config editor."

I'm not using any patch, so turning the pref ON would put me outside of comment #96. Testing this is too risky and convoluted for me right now. I'm already frustrated with Lightning's constant screen refreshing and slow performance, and I don't want to make things even worse.
Is this bug blocking bug 510850?  Regression?
I have tested (in bug 510850) this "calendar.network.multirealm" preference with two Google calendars and it's working marvelously!

Waiting impatiently for it to get into TB as default.
This issue is set to fixed. I still have the problem with password manager that passwords of different accounts on the same host are not saved.
Hi Rosali, have you set "calendar.network.multirealm" preference? (or https://bugzilla.mozilla.org/show_bug.cgi?id=510850#c13 for steps)

What calendar provider are you connecting to? Or send me a private mail and I'll try to help you in my spare time.
Please guide me how to do it. Where is the config file in Windows?
Rosali, this website is for bug-related records and progress but not particular support to individual user. I'll move your request off to private message.
I'm able to reproduce Rosali's problem.  But as per comment 107, I've filed a new Bug 799184
Hello,

I followed all the indications to the letter and it still does not work ...
I always have a yellow triangle that appears when I created my 2nd calendar.
Would you have another idea?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: