799184 - calendar.network.multirealm = true does not work with Digest authentication

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[石庭豐 (Seak, Teng-Fong)]

Attachment: mail4us cals are not working but Google cals are working perfectly

Although bug 247486 is marked as fixed, with Rosali, when we try to open multiple CalDAV calendars at mail4us.net with different credentials, the 2nd calendar failed to open.

CalDAV URLs for mail4us.net are like this:
http://dav.mail4us.net/calendars/tb1%40mail4us.net/events/
http://dav.mail4us.net/calendars/tb2%40mail4us.net/events/

Usernames are [e-mail] and [e-mail] respectively.  Passwords are the *same* (but not shown for security reason).

I'll upload an image showing that mail4us multi-calendars don't work.  As a comparison, I have opened two Google calendars and they are working perfectly (side by side with mail4us calendars).  In "Password manager", mail4us has ONE entry whereas Google has two entries as expected. Note that mail4us entry has no indication of the calendar name.

PS: I'm able to reproduce the problem in the following conditions:
* TB 13.0.1 + LT 1.5.2 on Win XP 32bit
* TB 15.0.1 + LT 1.7 on Win XP 32bit & Debian 6 32 bit
That's why I change Hardware and OS to "All" for this bug.

At the moment, we have no idea what went wrong.

Comment 1

[Stefan Sitter [:ssitter]]

Have you switched the preference that was added in Bug 247486 to change behavior to use username/password per calendar instead of username/password per calendar server?

Comment 2

[石庭豐 (Seak, Teng-Fong)]

You are talking about "calendar.network.multirealm"?  Yes, of course, otherwise multiple Google calendars wouldn't have worked either (cf attached image)

Comment 3

[Rosali]

If someone needs the password, just mail to myroundcube at mail4us dot net.

Comment 4

[石庭豐 (Seak, Teng-Fong)]

I've gone through quickly on comments of bug 247486. I barely understood everything. It seems to me that the fix of bug 247486 is actually a sort of hack because the core problem lies in the password manager.  Did I get it correct?

So, does CalDAV server need to provide something to support this hacked multi-calendar feature?

If needed, I could do some debugging.  Just tell me what to do. You could write to my e-addres.

Comment 5

[Philipp Kewisch [:Fallen][☁️📆]]

If you can get that server to report a different realm per calendar, then you might get away with not needing to set that multirealm pref.

Aside from that, we'd have to go through some debugging to see what the problem is.

Comment 6

[石庭豐 (Seak, Teng-Fong)]

I think I've found the first part of the problem.

In /calendar-js/calCalendarManager.js, at line 239, we have this code where the variable "authHeader" is a string containing the realm:
  let authHeader = channel.getResponseHeader("WWW-Authenticate");

Then at line 246, the code tries to add calendar name after realm:
  authHeader = authHeader.replace(/realm="(.*)"/, 'realm="$1 (' + calendar.name + ')"');

I printed out content of authHeader before and after line 246 and let's see what they give in practice.

For Google calendar, I have:
BASIC realm="Google CalDAV"
BASIC realm="Google CalDAV (G-Cal-1)"

But for mail4us.net, I have:
Digest realm="SabreDAV",qop="auth",nonce="5078189b25955",opaque="df58bdff8cf60599c939187d0b5c54de"
Digest realm="SabreDAV",qop="auth",nonce="5078189b25955",opaque="df58bdff8cf60599c939187d0b5c54de (tb1)"

Here, I think the modified string is supposed to be like this instead:
Digest realm="SabreDAV (tb1)",qop="auth",nonce="5078189b25955",opaque="df58bdff8cf60599c939187d0b5c54de"

but the code at line 246 made a greedy match from the first double quote after realm up to the last double quote of the string. So, my "quick and dirty" proposal is to do an ungreedy match like this :
authHeader = authHeader.replace(/realm="([^"]*)"/, 'realm="$1 (' + calendar.name + ')"');

However, this proposal is not complete because according to definition of quoted string in RFC 2616, a quoted string can contain escaped double-quote characters.  So the code doesn't work for a realm like this:
  realm="ABC \" EFG"

For the moment, I'm unable to make up a regex to process this case and I think we would need to make a function to take care of this.  But we can come back to this point later.

Back to our main problem -- with the "quick and dirty" proposal, now I have another problem:
I keep getting "Authentication Required" dialog popup asking for one credential after another (tb1, then tb2, then tb1, and so on).  Password manager is unable to store the password.

It would certainly take me very long time if I have to dig deeper all by myself into password manager mechanism, so if someone could shed a little light here, that would be great. For example, tell me what file to look at, or what keyword to search for to start with.

Comment 7

[Philipp Kewisch [:Fallen][☁️📆]]

Attachment: [checked in] Partial Fix - v1

I have a patch for the first part that works with escaping, not using a regex though since lookbehind expressions are not supported.

I have an idea what may be happening, that will make it impossible to use this workaround: I think the Digest authentication does a hash of the www auth header using the realm. Since we modify the realm, we will never get the right password sent to the server.

Unfortunately this means we will need to do some drastic changes to the way authentication works, nothing that I can quickly fix now. This might end up needing to be a core fix, as with the original bug.

Can you disable digest auth as a workaround?

Comment 8

[Martin Burnicki]

I've also stumbled over this bug.

Actually I've set up an owncloud server to share one or more calendars for several persons. The initial plan was to let every person have his own owncloud account, and then everyone could share his calendar with those persons who he wanted to share with.

However, until recently only owncloud 4.0.7 was available, which didn't support sharing of calendars properly, so we have set up a "public" account and every person authenticated with the same credentials. Unfortunately everybody could only use the shared calendars from the public account, but could not use any private calendar on the same server which would have required a different user name and password. 

Some days ago owncloud 4.5 was released, and sharing of calenders now works correctly, so I could authenticate with my personal owncloud account to see my private calendar plus all shared calendars.

Unfortunately it is not possible in Lightning to edit the caldav URL of existing calendars. So I deleted the old shared calendars and created new ones using the caldav links for my private account. However, Lightning (I'm using Lightning 1.7 with Seamonkey 2.12.1) just said the calenders were not reachable.

I figured out that Lightning still tried to authenticate using the user name and password it had stored in its password safe for theis server, so I had to delete these settings manually with Seamonkey's password manager and restart Seamonkey/Lightning to have Lightning ask for a new user name and password.

This is very annying. IMO a better solution would be to let the user name/password dialog pop up if authentication fails, and let the user update the settings. Or even add corresponding fields to the properties dialog so that you can simply change the setting e.g. if the password on the server has been changed.

BTW 1: A very nice feature would be a caldyv support where you just have to enter the base URL and credentials, Lightning queries a list of available calendars from the server, and you just have to mark the checkboxes for the calendars you want to use. That's the way it works e.g with iOS and CalDAV-Sync for Android.

BTW 2: If you have 10 calendars or so then it would be nice to have a mechanism to synchronize the calendar list between installations of Lightning on your PC and on your Laptop, possibly just by copying some config files between the machines. Otherwise it is hard to keep the calendar lists consistent between several machines, e.g. if calendars are added or removed, or if the caldav URLs have changed.

Comment 9

[石庭豐 (Seak, Teng-Fong)]

(In reply to Philipp Kewisch [:Fallen] from comment #7)
> I have a patch for the first part that works with escaping, not using a
> regex though since lookbehind expressions are not supported.

I saw you've added some code to escape special char in calendar name:  	
authHeader = appendToRealm(authHeader, "(" + calendar.name.replace('"','\\"')

But we actually need to escape "double quote" and "backslash" to comply to RFC 2616. Eg:
"A\B C"D" has to become "realm=SabreDAV (A\\B C\"D)"

Quite a headache!  Maybe you could simply forbid the use of '"' and '\' inside calendar name :)

In the code, I saw that CalDAV server always send back the original realm name during challenge even if calendar name was attached to realm in a previous challenge. So, I'm asking this question:
* When Lightning receives the challenge around line 239, does it have knowledge of the URL for which the challenge was issued?

Otherwise, I'm thinking, maybe we could do like this:
1. attach calendar name to realm and pass this to password manager
2. BUT send unmodified realm back to CalDAV server as a response

Rosali and I were also wondering why password manager doesn't store URL instead of realm.

Comment 10

[石庭豐 (Seak, Teng-Fong)]

(In reply to Martin Burnicki from comment #8)
> I've also stumbled over this bug.

Martin, please open a new bug for your problem, unless you're sure your problem is related to Digest authentication or SabreDAv.

For your other comments, some are available as other bugs already.

Comment 11

[Matthew Mecca [:mmecca]]

Comment on attachment 670906 [details] [diff] [review]
[checked in] Partial Fix - v1

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

Untested, but looks good. r=mmecca

::: calendar/base/src/calCalendarManager.js
@@ +154,4 @@
>                              // The provider may choose to explicitly disable the
>                              // rewriting, for example if all calendars on a
>                              // domain have the same credentials
> +                            authHeader = appendToRealm(authHeader, "(" + calendar.name.replace('"','\\"') + ")");

Should this be a global replace in case of multiple double-quote characters, and also escape the backslash character as mentioned in comment #9? Maybe something like:

calendar.name.replace('\\', '\\\\', 'g').replace('"', '\\"', 'g')

@@ +1112,5 @@
> +
> +function appendToRealm(authHeader, appendStr) {
> +    let isEscaped = false;
> +    let idx = authHeader.search(/realm="(.*?)(\\*)"/);
> +    if (idx > -1) {      

There are a few lines with extra whitespace in this function

Comment 12

[Philipp Kewisch [:Fallen][☁️📆]]

(In reply to Matthew Mecca [:mmecca] from comment #11)
> Should this be a global replace in case of multiple double-quote characters,
> and also escape the backslash character as mentioned in comment #9? Maybe
> something like:
> 
> calendar.name.replace('\\', '\\\\', 'g').replace('"', '\\"', 'g')
Thanks, I've changed this.

> 
> @@ +1112,5 @@
> > +
> > +function appendToRealm(authHeader, appendStr) {
> > +    let isEscaped = false;
> > +    let idx = authHeader.search(/realm="(.*?)(\\*)"/);
> > +    if (idx > -1) {      
> 
> There are a few lines with extra whitespace in this function
Fixed.

Comment 13

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 670906 [details] [diff] [review]
[checked in] Partial Fix - v1

Where did that checked-in+ flag go?? Anyway:

comm-central changeset e4e578dc3b45

Leaving open for the digest issue.

Comment 15

[alfadog]

Just to confirm this bug and add value to the troubleshooting process, I've encountered this issue using SabreDAV and a default setup in Windows. When I add multiple calendars from the same host, the password manager seems to get confused as to which one to use. When I change calender.network.multirealm to true, I repeatedly get asked for credentials.

I don't believe that this is an authentication issue.

I believe that it's simply an oversight in the password manager's storage/lookup fields.

If I set calender.network.multirealm to false and add 2 calendars from the same server like so:

https://localhost/SabreDAV/calendars/dan/default/ with a username of "dan", Realm of SabreDAV
http://localhost/SabreDAV/calendars/admin/default/ with a username of "admin", Realm of SabreDAV

The password manager will keep them both synchronized. I will get asked for a password for each one as I set it up, and both get remembered.

If I look in the "site" field of the password manager, I see 

"https://localhost (SabreDAV)"   dan
"http://localhost (SabreDAV)"   admin

If the path were included in the site field, and checked as the password is looked up by the calendar, I feel that the passwords would successfully be saved and reused.

Technically the same server could include a CardDAV server as well. When Thunderbird supports CardDAV without SOGo, it seems that this issue will show up again when we add multiple address books to our setup.

In summary, I believe that adding the path to the saved site in Password Manager will solve the problem.

Comment 16

[Yuv]

I am using Lighting 3.3.3, SOGo Connector 31.0.1, Thunderbird 31.4.0, everything up to date on Xubuntu 14.04LTS, and I've stumbled into this problem.

I totally agree with comment #15 above.  Please add the path to the saved site in Password Manager and solve the problem.

In the past two weeks I have tried to get Thunderbird to work with our other devices.  Both iPhone and Android works well with CardDAV/CalDAV (server-side I test with Radicale and Baikal).  I cannot say the same of Thunderbird and I am appalled to see that such essential functionality is broken for such long time.  Even the password-entry window is totally flawed: where the password-entry window for an email account will show the account name, the one for the calendar or address book won't.

Comment 17

[larsemoeller]

August 2015 and still no love...

This bug is an essential deal-breaker for private caldav servers.

Like commentator #15 I am also stuck either in an endless authentication loop (calender.network.multirealm = true) or with only one registered calendar (calender.network.multirealm = false) on my baikal setup.

Please fix this.

Thanks,
Nix

TB 31.8.0
Lightning 3.3.3

Comment 18

[info]

After just adding 2 extra CNAME DNS records on my caldav server to allow users to use CardDAV, CalDAV and Tasks at the same time I'm actually quite impressed how broken this is. The solution seems incredibly straightforward, add the full path (and the Type of object to sync as in a calendar/todo this can be both types on one calendar) to the pw storage for uniqueness and this should work.
If there is any testing to be done, I'd love to help out!

TB 38.7.0 Lightning 4.0.7

Comment 19

[Immy]

FYI, same issue, cannot have two calendars on same domain for different users. Resolved by removing all old calendars, setting "calendar.network.multirealm" to true and re-starting TB. TB 45.1.1, Windows Server 2008R2 Terminal Server

Comment 20

[benediktjmichal]

Same Issue, cannot have two calendars on the same domain TB 38.8.0, Ubuntu 16.04

Comment 21

[Lat]

Same issue here.

It is very easy to see the cause of the bug when you look at a packet trace

WWW-Authenticate: Digest realm="SabreDAV",qop="auth",nonce="...",opaque="..."

Authorization: Digest username="user", realm="SabreDAV (User Name)", nonce="...", uri="/calendars/user/default/", response="...", opaque="...", qop=auth, nc=00000001, cnonce="..."

Thunderbird/Lightning are clearly authenticating with an invalid realm that does not exist on the server "SabreDAV (User Name)". It seems evident to me that this was the solution used to allow Lightning/Password Manager to disambiguate between multiple accounts on the same server. However this bug was created in the process.

Is there a compelling reason the realm field was overridden to be used this way? It seems like a hack to me and I think it would have been much more preferable to prepend the user to the domain as is customary (aka [e-mail], [e-mail]), which would have been cleaner and made a lot more sense with the benefit of not causing the realm mismatch in this bug. 

Now that we are here and thuderbird is already overloading the realm field, it might be easier/less risky to hack off the excess " (User Name)" that isn't supposed to be there before generating the digest response. When correctly implemented it must return the exact same realm as requested by the server. In this case the value should be "SabreDAV", but the caldav server could change it so thunderbird should just truncate whatever portion of the string that it added.

Comment 22

[Lat]

By the way this is with "calendar.network.multirealm" turned on. When it's turned off obviously thunderbird has trouble storing multiple accounts.


The flag currently uses tuples in the form of "domain,realm (account name),user,password". That can be made to work, but it seems awkward as the realm and the account name might contain "()" characters themselves resulting in strings like this "Company(Florida)(Smiling (: Bob)".

While that's a bit silly, it shouldn't matter what the display name contains. Ideally this problem would be solved permanently and support all services out of the box with no need for any hidden flags either. It looks like the password manager is already capable of storing tuples in the form of "user@domain,realm,user,password", it would just be a matter of getting lightning to use it that way.

Comment 23

[Philipp Kewisch [:Fallen][☁️📆]]

The Mozilla Platform uses the origin and realm to see if a password needs to be requested. We've added the calendar name to the realm to make sure one password is requested per calendar. calendar.network.multirealm is a hack by itself and therefore not exposed to the UI or made the default, so this is a known limitation. This bug is about lifting that limitation, but there is no clear way to do that at the moment.

If you can configure the server for basic auth, or have the server include the calendar name in the realm (and turn calendar.network.multirealm off), this would be a workaround.

Comment 24

[Lat]

> The Mozilla Platform uses the origin and realm to see if a password needs to
> be requested. We've added the calendar name to the realm to make sure one
> password is requested per calendar. calendar.network.multirealm is a hack by
> itself and therefore not exposed to the UI or made the default, so this is a
> known limitation.

I understand that the realm is being modified client side so that the password manager can differentiate it, and I understand that is a hack. The reason I'm posting is to share the information I found about why the auth failure bug is happening, the client MUST authenticate using the same realm as the server whatever it is, the fact that it isn't doing that is the cause of this bug. If this is already known to you then my post may be redundant, however I am not sure this has been acknowledged yet.

> If you can configure the server for basic auth, or have the server include
> the calendar name in the realm (and turn calendar.network.multirealm off),
> this would be a workaround.

The least intrusive workaround I'll probably settle on because the infrastructure is already working perfectly with everything besides thunderbird/lightning is the one posted in the original bug report: use subdomains a.dav.server.com, b.dav.server.com, etc to force Thunderbird to treat them as different origins. The negative is that it breaks SSL certificates that aren't certified for subdomains.

> This bug is about lifting that limitation, but there is no clear way to do that at the moment.

Thunderbird's normal handling of imap and smtp maps perfectly to caldav. That would work equally well whether users needed multirealm or not. TBH I don't understand why password management for lightning was ever engineered differently than imap and smtp. All these webdav hacks including the multirealm setting look like over engineering to me when the solution is starring us right in the face: handle passwords exactly like imap and smtp. Can anyone establish any case where a user would be unable to use webdav password management this way?


It's clear that trying to authenticate using a modified realm is a bug with the client. The immediate fix would be to strip off the extra characters that got appended by the client to get back the original (and correct) realm, but IMHO that's just continuing to build on a hack. The best long term fix would be to manage passwords exactly like imap and smtp do.

Comment 25

[石庭豐 (Seak, Teng-Fong)]

About the realm and regarding SabreDAV, correct me if I'm wrong, I think it's the fault of SabreDAV.
According to RFC 2617, section 3.2.1 (https://tools.ietf.org/html/rfc2617#section-3.2.1)

   If a server receives a request for an access-protected object, and an
   acceptable Authorization header is not sent, the server responds with
   a "401 Unauthorized" status code, and a WWW-Authenticate header as
   per the framework defined above,.....

And look at the definition of realm:

   realm
     A string to be displayed to users so they know which username and
     password to use. This string should contain at least the name of
     the host performing the authentication and might additionally
     indicate the collection of users who might have access. An example
     might be "[e-mail]".

Now, let's look at the realm string sent by SabreDAV as provided in comment #21:
WWW-Authenticate: Digest realm="SabreDAV",qop="auth",nonce="...",opaque="..."

In RFC, it's written that "This string *should* contain at least the name of the host...." but SabreDAV does NOT form a correct realm.  It sent "SabreDAV" instead of host name (ie DNS host name).

The hack in Lightning to add the user between bracket is a *reaction/response* to the 'dirty' string sent by the server.

NB: Google also sends a dirty string.

PS: For the time being, there are at least two workarounds:
 1. Use multiple profile function of Thunderbird
 2. Use DNS alias and "invent" our own sub-domains to distinguish URL

Comment 26

[石庭豐 (Seak, Teng-Fong)]

(In reply to Lat from comment #24)
> [deleted]
> The best long
> term fix would be to manage passwords exactly like imap and smtp do.

IMHO, we should manage (CalDAV) passwords exactly like imap and smtp ONLY if it's clearly specified in the standard.

I'm no expert in CalDAV nor have I read through the whole RFC, but since authentication for CalDAV is based on HTTP 1.1 while IMAP and SMTP are not, the authentication "scheme" (or whatever you call it) is different.  In other words, more consideration and a better understanding of CalDAV standard are needed to choose the best way to manage password.

Comment 27

[Lat]

> About the realm and regarding SabreDAV, correct me if I'm wrong, I think
> it's the fault of SabreDAV.
> According to RFC 2617, section 3.2.1
> (https://tools.ietf.org/html/rfc2617#section-3.2.1)
> 
>    If a server receives a request for an access-protected object, and an
>    acceptable Authorization header is not sent, the server responds with
>    a "401 Unauthorized" status code, and a WWW-Authenticate header as
>    per the framework defined above,.....
> 

SabreDAV handles authentication correctly when the client authenticates using the correct realm (Lightning is the only DAV client I've personally encountered that does not).
Is it possible that SabreDAV could "fix" this by ignoring the incorrect realm and proceeding with normal authentication anyways? Possibly, but if I recall SabreDAV authenticates the client using a hash of all the fields including realm and password. In order to workaround clients that send back a buggy realm, SabreDAV would necessarily have to exclude realm from the hash and all the hashes would need to be regenerated. So it might work, but not using the correct realm is technically wrong and might actually create new problems for some large orgs that want to use realms.


> Now, let's look at the realm string sent by SabreDAV as provided in comment
> #21:
> WWW-Authenticate: Digest realm="SabreDAV",qop="auth",nonce="...",opaque="..."
> 
> In RFC, it's written that "This string *should* contain at least the name of
> the host...." but SabreDAV does NOT form a correct realm.  It sent
> "SabreDAV" instead of host name (ie DNS host name).
> 
> The hack in Lightning to add the user between bracket is a
> *reaction/response* to the 'dirty' string sent by the server.
> 

Disagree, the client isn't supposed to parse or modify the realm at all, just use it as is in the authentication response. When realm is the name of the host, Lightning still has this bug anyways, so this isn't a good reason not to fix the bug. In any case who's to say that "SabreDAV" isn't the hostname?

 
> PS: For the time being, there are at least two workarounds:
>  1. Use multiple profile function of Thunderbird

#1 does not work (in fact Lightning's implementation of #1 is the cause of the bug).
To be clear, there's no authentication bug in single profile mode. The *only* problem with this is that Lightning can't store more than one user account this way.

Lightning needed a way to force the password manager to hold more than one user account per server, but unfortunately developers "solved" this problem poorly, by appending a username to the realm. This solved the problem of storing multiple accounts in Thunderbird's password manager, but due to an implementation bug (not stripping the username back off before reusing the field), they created this authentication bug.

The key to fixing this bug in Lightning is that it must not corrupt the realm string. Either strip off the erroneous data before sending it back to the server, or use Thunderbird's password storage the exact same way imap and smtp works. The later would have been the optimal way to design this feature from the get go (with no need for a "multi profile mode").

Comment 28

[Lat]

> IMHO, we should manage (CalDAV) passwords exactly like imap and smtp ONLY if
> it's clearly specified in the standard.
> 
> I'm no expert in CalDAV nor have I read through the whole RFC, but since
> authentication for CalDAV is based on HTTP 1.1 while IMAP and SMTP are not,
> the authentication "scheme" (or whatever you call it) is different.  In
> other words, more consideration and a better understanding of CalDAV
> standard are needed to choose the best way to manage password.

I think there's some confusion here, I was not asking for any changes to the protocol on the wire. When I say we should manage caldav passwords exactly like imap and smtp, I'm only referring to how passwords are stored locally. How we store passwords locally is completely tangential to the spec. It could be in an SQL database, in a CSV file, a JSON record, in Thunderbird's password manager, or whatever, this is not relevant to the protocol. However in lightning's case it is the cause of the bug.

Lightning's DAV code already works perfectly, and I'm not asking for it to be changed. This bug only originated from the way Lightning attempts to store multiple usernames inside of Thunderbird, that's the bug. It has nothing to do with the protocol and nothing to do with the RFC.

Comment 29

[Lat]

> > PS: For the time being, there are at least two workarounds:
> >  1. Use multiple profile function of Thunderbird
> 
> #1 does not work (in fact Lightning's implementation of #1 is the cause of
> the bug).


Sorry Seak Teng-Fong, I may have misunderstood you here. On re-reading I think you meant a separate Thunderbird instance running a different profile. Yeah, now I see it would be a workaround. Although it would be confusing and annoying to have to use multiple instances of thunderbird to coordinate calendar events. For example I have calendars for personal, family, and work and it's extremely helpful to see all three in the same interface at the same time.

Lightning already supports multiple calendars per profile, it's just a shame that two independent DAV accounts can't be on the same domain because of this realm bug.

Given that it's just a local storage problem and not a protocol problem, I don't think it should be that difficult to fix: ensure the values we get back out of storage are exactly the same as those that were saved to begin with (ie don't corrupt the realm).

Comment 30

[hartnegg]

I can confirm comment 21:
The server complains that it received an invalid realm.
Thunderbird sent realm="UserDav (Test-Calendar)".
In Digest Authorization the realm is provided by the server in its initial http 401 response, and must not be modified by the browser.

Ideally Thunderbird should use a combination of servername and username as index for the password database, not the name of the calendar or the realm.

Comment 31

[hartnegg]

Regarding password storage requirements:

It is probably impossible to have different passwords for different calendars in the same account. Same for realms CalDAV and UserDAV.

iOS does not even have a dialog to add one single calendar. It only has a dialog to add a whole CalDAV account. For that it wants server, username, password and comment. If iOS does not offer different passwords for different calenders, then this is probably never needed.

But it is of course necessary to store different passwords for different users of the same server.

Comment 32

[Lat]

(In reply to hartnegg from comment #31)
> It is probably impossible to have different passwords for different
> calendars in the same account. Same for realms CalDAV and UserDAV.
> 
> iOS does not even have a dialog to add one single calendar. It only has a
> dialog to add a whole CalDAV account. For that it wants server, username,
> password and comment. If iOS does not offer different passwords for
> different calenders, then this is probably never needed.

Yes, the logins are per account, which in turn has an arbitrary number of calendars. I haven't used IOS but on android the stock calendar app and 3rd party apps like "etar" let you add as many accounts as you have and select which calendars from within those accounts to display. There's clearly no calDAV limitation on having only one user account per realm, this artificial limitation came about in lightning because passwords are erroneously stored per-realm rather than per account. The multi-realm flag was an attempt at a fix, but obviously was buggy due to mangling the server's realm string.

> But it is of course necessary to store different passwords for different
> users of the same server.

Lightning saves passwords per realm, but this is wrong. It should be saving passwords per account instead like other clients do. To fix this I would be inclined to abandon the broken/unnecessary multi-realm flag, which everyone agrees is a lightning specific hack. Instead, we should really fix the password storage bug that prevents us from using multiple accounts per realm.

Is the impediment to getting this fixed merely a matter of developer resources or are there still technical disagreements? Because if so, I would like to get those disagreements ironed out!

Comment 33

[alan]

I can confirm that I have the same issue with two different accounts on Zoho.com. I'm using Thunderbird/Lightning V52.5.2 on Linux and I have calendar.network.multirealm set to true in preferences -> advanced -> config.

Each account is part of a different domain name (hence different accounts) hosted by Zoho - however, the base URL to access each account is the same - https://calendar.zoho.com/ and the domain is part of the username - i.e. its the user's primary email address for that domain name.

Each account has multiple calendars, but only one account can be active. When I delete the specific entry from the password manager and restart Thunderbird I am prompted for the username and password for calendar.zoho.com (no reference is made to the associated email address which is the username) - depending which account I use to login, enables which set of calendars.

I also use the CardBook plugin for Thunderbird for carddav - CardBook works fine with the two accounts. Like the caldav server, the accounts use the same domain URL: https://contacts.zoho.com. The difference is that each account has its own entry in the password manager.

So while I agree, saving credentials just by realm/base domain doesn't work, saving per account is not 100% right either, it needs to be both parameters to define the login, i.e. the base domain AND the username.

I'm the admin for both of these domains on Zoho if you need test accounts - please PM me if you need test accounts.

Thanks

Comment 34

[Lat]

> So while I agree, saving credentials just by realm/base domain doesn't work,
> saving per account is not 100% right either, it needs to be both parameters
> to define the login, i.e. the base domain AND the username.
> 


I'd like to use your webdav configuration on my server too if thunderbird supported it.

I looked at my android client, and it's primary key is the full url (domain + uri) and username. I don't know if anybody uses it, but webdav is supposed to support realms.

So the full primary key for one account should be:
URL (https://santa.net/webdav/...)
REALM (northpole)
USERNAME (santa)

And each account may have multiple calendars.


I'm the admin for both of these domains on Zoho if you need test accounts - please PM me if you need test accounts.
> I'm the admin for both of these domains on Zoho if you need test accounts -
> please PM me if you need test accounts.
> 
> Thanks


I'm not sure if anyone's monitoring this bug, but I'm also happy to volunteer technical assistance/testing/debugging on my end too (currently running SabreDAV).

Comment 35

[zaadstra]

Hi,

what is the current status?  I have a Baïkal CalDAV server (sabredav) and am running into this issue. After not getting to show two calendars on the server I set calendar.network.multirealm to False again, deleted calendars and accounts but now I even can't configure one working calendar. It keeps asking for credentials. So it appears to be really messed up now ...

Thunderbird 52.9.1
Lightning 5.4.9.1
CalDAV WebDAV authentication type: Digest.
URL: http://piii:3838/cal.php/calendars/hans/default/

This bug is also mentioned in 247486 and 707138.

Where can I find logging on the connection to the CalDAV server?

Thanks

Comment 36

[Philipp Kewisch [:Fallen][☁️📆]]

There is no work being done on this bug at the moment, although it has been readily confirmed.

Comment 37

[zaadstra]

Thanks Philipp for the update.

After even more fiddling I can connect to only one calendar again.....

Interesting to know, I also use the CardBook plugin from Philippe Vigneau (https://addons.thunderbird.net/en-US/thunderbird/addon/cardbook/) that connects to the same Baïkal server for synchronizing contacts using CardDAV.
So multible connections should be possible ;-)

Comment 38

[zaadstra]

.... that connects to the same Baïkal server for synchronizing contacts using CardDAV.

With multiple accounts,  I forgot to mention.

Comment 39

[Dag Bakke]

(In reply to zaadstra from comment #35)

> Where can I find logging on the connection to the CalDAV server?
> 

@zaadstra :
From #707138 :

Please be sure to provide information with debug logging enabled (calendar.debug.log and calendar.debug.log.verbose in the advanced config editor) and describe what caldav server you are using, and if the calendars all have the same authentication details, and if you know it also the auth mechanism (basic, digest).

For anyone else passing by and pulling hairs because you cannot get multiple CalDAV calendars on the same server working (in thunderbird 60.2.1 or earlier):

0. Preferences | Advanced | Config Editor
Set calendar.network.multirealm to True
 
1. Add all calendars. They will not work

2. Delete passwords for the relevant calendars (Preferences | Security | Saved Passwords)

3. Restart Thunderbird


You will get a prompt for each calendar added. However, which prompt connects to which calendar is not declared anywhere visible. You are running blind and have to try. Remember to check the save password prompt. If you fail, try again from point 2.

@Mozilla in general: thank you for firefox and thunderbird. Keep up the good work.

Comment 40

[Dag Bakke]

(in thunderbird 60.2.1 or earlier)  should be: (at least in thunderbird 60.2.1 or earlier)

Comment 41

[Alexander B.]

Current state

• TB 68.12.1
• against a baikal DAV server (based on sabre/dav) with DIGEST
• using TB-Sync add-on.
• against one domain, having set calendar.network.multirealm = true

Issue still exists - Lightning is messing with things when using Digest and thus AUTH fails
Funny observation: things work for the initial sync in the TB-Sync dialogue, but as soon as Lightning kicks in... :(

Workaround:

• use one subdomain per account (might mess up your SSL certs)
• in baikal / sabre switch to BASIC auth (AND USE HTTPS!)