mozilla uses same auth info for different calendars at the same server

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://<email address hidden>/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. ***

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

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 "<email address hidden>". So, I specify the Location URL as: https://<email address hidden>@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:

<email address hidden>
<email address hidden>

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.

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.

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.

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:<email address hidden>/cal/calname.ics
http://myuser:<email address hidden>/cal/calname2.ics
http://myuser:<email address hidden>/cal/calname3.ics
http://myuser:<email address hidden>/cal/calname4.ics
http://myuser:<email address hidden>/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

*** Bug 371753 has been marked as a duplicate of this bug. ***

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:<email address hidden>: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://<email address hidden>.... 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.

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://<email address hidden>/events
https://<email address hidden>/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.

*** Bug 475188 has been marked as a duplicate of this bug. ***

*** Bug 484779 has been marked as a duplicate of this bug. ***

*** Bug 540907 has been marked as a duplicate of this bug. ***

*** Bug 500197 has been marked as a duplicate of this bug. ***

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 <email address hidden>" and "ssh <email address hidden>" 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?

*** Bug 577468 has been marked as a duplicate of this bug. ***

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.

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.

> 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.

Needs to be taken care of asap, especially since it causes an exception sometimes.

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.

Created attachment 560126
Pref off - v1

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.

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
Pref off - v1

Untested, but codewise r=mmecca

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/dc0820370836>
-> FIXED

Backported to comm-aurora <http://hg.mozilla.org/releases/comm-aurora/rev/5827d8225ac4>

Backported to comm-beta <http://hg.mozilla.org/releases/comm-beta/rev/2aed8aff80c9>

*** Bug 365036 has been marked as a duplicate of this bug. ***

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://<email address hidden>/calendar
https://<email address hidden>/calendar

workaround works if I change hostname, e.g.
https://<email address hidden>/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?

*** Bug 510850 has been marked as a duplicate of this bug. ***

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

*** Bug 1368478 has been marked as a duplicate of this bug. ***

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?