Closed Bug 447824 Opened 16 years ago Closed 15 years ago

Fix caldav ticket-based authentication

Categories

(Calendar :: Provider: CalDAV, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: luknic, Assigned: Fallen)

References

Details

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

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Thunderbird 2.0.0.16 (20080708) + Lightning 0.9pre (2008012218)

Similar as in this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=373439
but it doesn't work in Sunbird too, I was trying Lightning 0.8 too.
I'm using chandler project server for calDav. 
Strangest thing is that when I add task / event do that calendar, it appears on online calendar, but not in lightning.
First I was thinking, that it is chandler related problem, but everything works fine after adding the first caldav calendar. After restart I see only my calendar/task and not calendars/task from shared calendars.

Reproducible: Always

Steps to Reproduce:
1.add caldav calendar
2.restart thunderbird
Actual Results:  
shared calendars disappears, only my own calendars/tasks are shown

Expected Results:  
to see all calendars

when thunderbird is starting, following error is shown:

An error was encountered preparing the calendar located at moz-abmdbdirectory://abook.mab for use. It will not be available.

datails:
Error number: 0xTypeError: ypeError: Components.classes["@mozilla.org/calendar/calendar;1?type=" + type] has no properties
Description:  TypeError: Components.classes["@mozilla.org/calendar/calendar;1?type=" + type] has no properties

This error doesn't appear in Lightning 0.8
> An error was encountered preparing the calendar located at
> moz-abmdbdirectory://abook.mab for use. It will not be available.

This error message indicates that your have created a calendar using the ThunderBirthDay extension. Either the extension is disabled or the extension tries to load an address book that no longer exists. In both cases the calendar initialization fails. The former issue can be improved with Bug 439620. The latter issue is a bug in the ThunderBirthDay extension that needs to be fixed by the extension author.
Martin, can you still reproduce this issue with a recent Lightning 0.9pre nightly build?
The error related to missing calendar is still there, but it is due the ThunderBirthDay incompatibility with Lightning 0.9 pre.

The second problem is still there too. From chandlerproject (https://chandlerproject.org) I can see only calDav calendars that I have created, and shared calendars, that can I only read. If is there shared calendar with full access for me, I can't see that calendar and tasks from it in lightning. (This calendars are visible only after first start with newly installed lightning, after restarting thunderbid, I can't see it)
I forgot to write, that, after installing the nightly build I can see now warning mark, and text: The calendar ... is momentarily not available.
But it is only with shared calendars, with full access for me.
After installing Lightning 0.9RC1 in Thunderbird 2.0.0.16 (Windows XP SP3) all my Google calendars showed an error and didnΒ΄t load. ThunderBirthDayextension isnΒ΄t installed. 

Error:
An error was encountered preparing the calendar located at
http:/www.google.com/calendar/feeds/XXXXXXgroup.calendar.google.com/provate-XXX for use. It will not be available.

Details:
Error number: 0xTypeError: Components.classes["@mozilla.org/calendar/calendar;1?type=" + type] has no properties
Description:  TypeError:
Components.classes["@mozilla.org/calendar/calendar;1?type=" + type] has no
properties
Sorry for my previous comment. Looks like Provider for Google Calendar sttoped working with 0.9RC1
So aside from the provider for Google calendar, this bug is still in 0.9rc1? The type error is not related to the caldav provider.

Martin (Luknic), do you have any error console messages? If nothing interesting is there, please create two new boolean prefs in the advanced config editor (Options>Advanced>General>Config Editor) called "calendar.debug.log" and "calendar.debug.log.verbose" and set both to true, then restart. You should get a bunch of error console messages that should help to debug the problem.
This is all I can get from the console related to one of not working calendar. (first time after installing lightning, I was able to see this calendar)

Warning1:
Warning: There has been an error reading data for calendar: Vrana.  However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description: 

Warning2:
Warning: There has been an error reading data for calendar: Vrana.  However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at https://hub.chandlerproject.org/dav/collection/85743248-597b-11dd-f7b7-001b6393426b?ticket=o2ereh7x01 is either not a DAV collection or not available

(calendar is user and password protected, so I let the link there)

Info1:
CalDAV: recv: <?xml version='1.0' encoding='UTF-8'?><D:error xmlns:D="DAV:" xmlns:cosmo="http://osafoundation.org/cosmo/DAV"><cosmo:not-found /></D:error>

Info2:
CalDAV: Authentication scheme Ticket

Info3:
CalDAV: Status 404 on initial PROPFIND for calendar Vrana
As info3 says, the initial propfind could not be done. This one looks like:

<D:propfind xmlns:D="DAV:" xmlns:CS={CS}>
  <D:prop>
    <D:resourcetype/>
    <D:owner/>
    <CS:getctag/>
  </D:prop>
</D:propfind>

And should not produce a 404, but rather a 207. What URL are you using to access the cosmo server? Please make sure this is the correct one.
Do any of the calendars that do work also use ticket-based authentication (i.e. does their url end with the ?ticket=XXXXXXX business)?
the working calendar url doesn't end with ?ticket=XXXXXXX
Looks like our support for ticket-based auth is broken. I'll fix that. I should also mention that on my own Chandler 1.1.0 install when I gin up these ticketed URLs  I get a URL with /pim/ in the middle that does not work - but if I change the /pim/ to /dav/ it does. This does not appear to affect hub, since that gets tinkered with wrt paths, but will be a (Chandler) bug for those running their own Chandler instances. 

I don't think this should block 0.9
Assignee: nobody → browning
Attached patch fix ticket-based auth, improve LOGing (obsolete) β€” β€” Splinter Review
This patch fixes ticket-based authentication; also improves CalDAV LOGing to include method and calendar, for help in multi-cal profiles. It assumes that the patch in bug 455262 is in place.
Attachment #340837 - Flags: review?(philipp)
I was pointed to this bug as a possible reason for my troubles too.

I have been using TB + Lightning for over a year with our calendar collections resident on our own hosted Cosmo (Chandler) server. Everything has been working flawlessly until I upgraded to Lightning 0.9.

Now, I cannot add new tasks or events from within Lightning. Clicking the "Save and Close" button in the dialogue results in noting happening. There are some errors reported in the console (below). My TB is now 2.0.0.17, host is Ubuntu Intrepid Ibex (8.10) with all updates installed.

As I said, it worked fine up until I upgraded Lightning. Nothing else has changed.

I have just tested something else. One of my calendars does not have the "?ticket" suffix to the url. That one seems to work fine.
http://10.0.0.2:8080/cosmo/dav/collection/XXXXXXXXXXXXXX-XXXXXXXXXX

The problem occurs with collections which use the ?ticket extension, e.g.
http://10.0.0.2:8080/cosmo/dav/collection/XXXXXX-XXXX-XXXXXX?ticket=kzo9yesqa0

I attempted to patch calDavCalendar.js with the previous post. But 6 out of 32 hunks failed. I can't see an "attach file" option so I have pasted the contents of the .rej file below.

*************** calDavCalendar.prototype = {
*** 803,841 ****
      safeRefresh: function caldav_safeRefresh(aChangeLogListener) {
          this.ensureTargetCalendar();
  
          if (this.mAuthScheme == "Digest") {
              // the auth could have timed out and be in need of renegotiation
              // we can't risk several calendars doing this simultaneously so
              // we'll force the renegotiation in a sync query, using HEAD to keep
              // it quick
-             var headchannel = calPrepHttpChannel(this.calendarUri, null, null,
                                                   this);
              headchannel.requestMethod = "HEAD";
              headchannel.open();
          }
  
          if (!this.mCtag || !this.mFirstRefreshDone) {
-             this.getUpdatedItems(this.calendarUri, aChangeLogListener);
              return;
          }
          var thisCalendar = this;
  
          var D = new Namespace("D", "DAV:");
          var CS = new Namespace("CS", "http://calendarserver.org/ns/");
          var queryXml = <D:propfind xmlns:D={D} xmlns:CS={CS}>
                          <D:prop>
                              <CS:getctag/>
                          </D:prop>
                          </D:propfind>;
          if (this.verboseLogging()) {
-             LOG("CalDAV: send: " + queryXml);
          }
-         var httpchannel = calPrepHttpChannel(this.calendarUri,
                                               queryXml,
                                               "text/xml; charset=utf-8",
                                               this);
          httpchannel.setRequestHeader("Depth", "0", false);
          httpchannel.requestMethod = "PROPFIND";
  
          var streamListener = {};
          streamListener.onStreamComplete =
--- 803,841 ----
      safeRefresh: function caldav_safeRefresh(aChangeLogListener) {
          this.ensureTargetCalendar();
  
          if (this.mAuthScheme == "Digest") {
              // the auth could have timed out and be in need of renegotiation
              // we can't risk several calendars doing this simultaneously so
              // we'll force the renegotiation in a sync query, using HEAD to keep
              // it quick
+             var headchannel = calPrepHttpChannel(this.makeUri(""), null, null,
                                                   this);
              headchannel.requestMethod = "HEAD";
              headchannel.open();
          }
  
          if (!this.mCtag || !this.mFirstRefreshDone) {
+             this.getUpdatedItems(this.makeUri(""), aChangeLogListener);
              return;
          }
          var thisCalendar = this;
  
          var D = new Namespace("D", "DAV:");
          var CS = new Namespace("CS", "http://calendarserver.org/ns/");
          var queryXml = <D:propfind xmlns:D={D} xmlns:CS={CS}>
                          <D:prop>
                              <CS:getctag/>
                          </D:prop>
                          </D:propfind>;
          if (this.verboseLogging()) {
+             LOG("CalDAV: PROPFIND " + this.makeUri("") + "\n"  + queryXml);
          }
+         var httpchannel = calPrepHttpChannel(this.makeUri(""),
                                               queryXml,
                                               "text/xml; charset=utf-8",
                                               this);
          httpchannel.setRequestHeader("Depth", "0", false);
          httpchannel.requestMethod = "PROPFIND";
  
          var streamListener = {};
          streamListener.onStreamComplete =
*************** calDavCalendar.prototype = {
*** 845,881 ****
                      " checking ctag for calendar " + thisCalendar.name);
              } catch (ex) {
                  LOG("CalDAV: Error without status on checking ctag for calendar " +
                      thisCalendar.name);
              }
  
              var str = convertByteArray(aResult, aResultLength);
              if (!str) {
-                 LOG("CalDAV: Failed to get ctag from server");
              } else if (thisCalendar.verboseLogging()) {
-                 LOG("CalDAV: recv: " + str);
              }
  
              if (str.substr(0,6) == "<?xml ") {
                      str = str.substring(str.indexOf('<', 2));
              }
              try {
                  var multistatus = new XML(str);
              } catch (ex) {
-                 LOG("CalDAV: Failed to get ctag from server");
                  return;
              }
  
              var ctag = multistatus..CS::getctag.toString();
              if (!ctag.length || ctag != thisCalendar.mCtag) {
                  // ctag mismatch, need to fetch calendar-data
                  thisCalendar.mCtag = ctag;
                  thisCalendar.mTargetCalendar.setMetaData("ctag", ctag);
-                 thisCalendar.getUpdatedItems(thisCalendar.calendarUri, aChangeLogListener);
                  if (thisCalendar.verboseLogging()) {
                      LOG("CalDAV: ctag mismatch on refresh, fetching data for calendar "
                          + thisCalendar.name);
                  }
              } else {
                  if (thisCalendar.verboseLogging()) {
                      LOG("CalDAV: ctag matches, no need to fetch data for calendar "
                          + thisCalendar.name);
--- 845,881 ----
                      " checking ctag for calendar " + thisCalendar.name);
              } catch (ex) {
                  LOG("CalDAV: Error without status on checking ctag for calendar " +
                      thisCalendar.name);
              }
  
              var str = convertByteArray(aResult, aResultLength);
              if (!str) {
+                 LOG("CalDAV: Failed to get ctag from server for calendar " + thisCalendar.name);
              } else if (thisCalendar.verboseLogging()) {
+                 LOG("CalDAV: recv from calendar " + thisCalendar.name + ":\n" + str);
              }
  
              if (str.substr(0,6) == "<?xml ") {
                      str = str.substring(str.indexOf('<', 2));
              }
              try {
                  var multistatus = new XML(str);
              } catch (ex) {
+                 LOG("CalDAV: Failed to get ctag from server for calendar" + thisCalendar.name);
                  return;
              }
  
              var ctag = multistatus..CS::getctag.toString();
              if (!ctag.length || ctag != thisCalendar.mCtag) {
                  // ctag mismatch, need to fetch calendar-data
                  thisCalendar.mCtag = ctag;
                  thisCalendar.mTargetCalendar.setMetaData("ctag", ctag);
+                 thisCalendar.getUpdatedItems(thisCalendar.makeUri(""), aChangeLogListener);
                  if (thisCalendar.verboseLogging()) {
                      LOG("CalDAV: ctag mismatch on refresh, fetching data for calendar "
                          + thisCalendar.name);
                  }
              } else {
                  if (thisCalendar.verboseLogging()) {
                      LOG("CalDAV: ctag matches, no need to fetch data for calendar "
                          + thisCalendar.name);
*************** calDavCalendar.prototype = {
*** 973,991 ****
                  responseStatus = "none";
              }
  
              if (responseStatus == 207) {
                  // We only need to parse 207's, anything else is probably a
                  // server error (i.e 50x).
                  var str = convertByteArray(aResult, aResultLength);
                  if (!str) {
-                     LOG("CAlDAV: Failed to parse getetag PROPFIND");
                  } else if (thisCalendar.verboseLogging()) {
-                     LOG("CalDAV: recv: " + str);
                  }
  
                  if (str.substr(0,6) == "<?xml ") {
                      str = str.substring(str.indexOf('<', 2));
                  }
                  var multistatus = new XML(str);
                  for (var i = 0; i < multistatus.*.length(); i++) {
                      var response = new XML(multistatus.*[i]);
--- 973,992 ----
                  responseStatus = "none";
              }
  
              if (responseStatus == 207) {
                  // We only need to parse 207's, anything else is probably a
                  // server error (i.e 50x).
                  var str = convertByteArray(aResult, aResultLength);
                  if (!str) {
+                     LOG("CAlDAV: Failed to parse getetag PROPFIND for calendar"
+                         + thisCalendar.name);
                  } else if (thisCalendar.verboseLogging()) {
+                     LOG("CalDAV: recv from " + thisCalendar.name + ":\n" + str);
                  }
  
                  if (str.substr(0,6) == "<?xml ") {
                      str = str.substring(str.indexOf('<', 2));
                  }
                  var multistatus = new XML(str);
                  for (var i = 0; i < multistatus.*.length(); i++) {
                      var response = new XML(multistatus.*[i]);
*************** calDavCalendar.prototype = {
*** 1013,1041 ****
                          itemsNeedFetching.push(resourcePath);
                      }
                  }
              } else if (Math.floor(responseStatus / 100) == 4) {
                  // A 4xx error probably means the server doesn't support this
                  // type of query. Disable it for this session. This doesn't
                  // really match the spec (which requires a 207), but it works
                  // around bugs in Google and eGroupware 1.6.
-                 LOG("CalDAV: Server doesn't support " + itemType + "s");
                  var itemTypeIndex = thisCalendar.supportedItemTypes.indexOf(itemType);
                  if (itemTypeIndex > -1) {
                      thisCalendar.supportedItemTypes.splice(itemTypeIndex, 1);
                  }
              } else {
                  unhandledErrors++;
              }
  
              var needsRefresh = false;
  
              if (unhandledErrors) {
-                 LOG("CalDAV: Error fetching item etags");
                  thisCalendar.reportDavError(Components.interfaces.calIErrors.DAV_REPORT_ERROR);
                  if (thisCalendar.isCached && aChangeLogListener) {
                      aChangeLogListener.onResult({ status: Components.results.NS_ERROR_FAILURE },
                                                  Components.results.NS_ERROR_FAILURE);
                  }
                  return;
              }
              if (thisCalendar.isCached) {
--- 1014,1043 ----
                          itemsNeedFetching.push(resourcePath);
                      }
                  }
              } else if (Math.floor(responseStatus / 100) == 4) {
                  // A 4xx error probably means the server doesn't support this
                  // type of query. Disable it for this session. This doesn't
                  // really match the spec (which requires a 207), but it works
                  // around bugs in Google and eGroupware 1.6.
+                 LOG("CalDAV: Server doesn't support " + itemType + "s for calendar "
+                     + thisCalendar.name);
                  var itemTypeIndex = thisCalendar.supportedItemTypes.indexOf(itemType);
                  if (itemTypeIndex > -1) {
                      thisCalendar.supportedItemTypes.splice(itemTypeIndex, 1);
                  }
              } else {
                  unhandledErrors++;
              }
  
              var needsRefresh = false;
  
              if (unhandledErrors) {
+                 LOG("CalDAV: Error fetching item etags for calendar " + thisCalendar.name);
                  thisCalendar.reportDavError(Components.interfaces.calIErrors.DAV_REPORT_ERROR);
                  if (thisCalendar.isCached && aChangeLogListener) {
                      aChangeLogListener.onResult({ status: Components.results.NS_ERROR_FAILURE },
                                                  Components.results.NS_ERROR_FAILURE);
                  }
                  return;
              }
              if (thisCalendar.isCached) {
*************** calDavCalendar.prototype = {
*** 1112,1128 ****
              thisCalendar.getCalendarData(aUri,
                                           multigetQueryString,
                                           null,
                                           null,
                                           aChangeLogListener);
          };
  
          if (this.verboseLogging()) {
-             LOG("CalDAV: send: " + queryString);
          }
  
          var httpchannel = calPrepHttpChannel(aUri,
                                               queryString,
                                               "text/xml; charset=utf-8",
                                               this);
          httpchannel.requestMethod = "PROPFIND";
          httpchannel.setRequestHeader("Depth", "1", false);
--- 1114,1130 ----
              thisCalendar.getCalendarData(aUri,
                                           multigetQueryString,
                                           null,
                                           null,
                                           aChangeLogListener);
          };
  
          if (this.verboseLogging()) {
+             LOG("CalDAV:PROPFIND " + aUri.spec + ":\n" + queryString);
          }
  
          var httpchannel = calPrepHttpChannel(aUri,
                                               queryString,
                                               "text/xml; charset=utf-8",
                                               this);
          httpchannel.requestMethod = "PROPFIND";
          httpchannel.setRequestHeader("Depth", "1", false);
*************** calDavCalendar.prototype = {
*** 1382,1414 ****
              } catch (ex) {
                  // no auth header could mean a public calendar
                  thisCalendar.mAuthScheme = "none";
              }
  
              if (thisCalendar.mUriParams) {
                  thisCalendar.mAuthScheme = "Ticket";
              }
-             LOG("CalDAV: Authentication scheme " + thisCalendar.mAuthScheme);
              // we only really need the authrealm for Digest auth
              // since only Digest is going to time out on us
              if (thisCalendar.mAuthScheme == "Digest") {
                  var realmChop = wwwauth.split("realm=\"")[1];
                  thisCalendar.mAuthRealm = realmChop.split("\", ")[0];
-                 LOG("CalDAV: realm " + thisCalendar.mAuthRealm);
              }
  
              var str = convertByteArray(aResult, aResultLength);
              if (!str) {
-                 LOG("CalDAV: Failed to determine resource type");
                  thisCalendar.completeCheckServerInfo(aChangeLogListener,
                                                       Components.interfaces.calIErrors.DAV_NOT_DAV);
                  return;
              } else if (thisCalendar.verboseLogging()) {
-                 LOG("CalDAV: recv: " + str);
              }
  
              if (str.substr(0,6) == "<?xml ") {
                  str = str.substring(str.indexOf('<', 2));
              }
              try {
                  var multistatus = new XML(str);
              } catch (ex) {
--- 1386,1419 ----
              } catch (ex) {
                  // no auth header could mean a public calendar
                  thisCalendar.mAuthScheme = "none";
              }
  
              if (thisCalendar.mUriParams) {
                  thisCalendar.mAuthScheme = "Ticket";
              }
+             LOG("CalDAV: Authentication scheme for calendar " + thisCalendar.name
+                 + ": " + thisCalendar.mAuthScheme);
              // we only really need the authrealm for Digest auth
              // since only Digest is going to time out on us
              if (thisCalendar.mAuthScheme == "Digest") {
                  var realmChop = wwwauth.split("realm=\"")[1];
                  thisCalendar.mAuthRealm = realmChop.split("\", ")[0];
+                 LOG("CalDAV: realm of " + thisCalendar.name + ": " + thisCalendar.mAuthRealm);
              }
  
              var str = convertByteArray(aResult, aResultLength);
              if (!str) {
+                 LOG("CalDAV: Failed to determine resource type of calendar " + thisCalendar.name);
                  thisCalendar.completeCheckServerInfo(aChangeLogListener,
                                                       Components.interfaces.calIErrors.DAV_NOT_DAV);
                  return;
              } else if (thisCalendar.verboseLogging()) {
+                 LOG("CalDAV: rec from " + thisCalendar.name + ":\n" + str);
              }
  
              if (str.substr(0,6) == "<?xml ") {
                  str = str.substring(str.indexOf('<', 2));
              }
              try {
                  var multistatus = new XML(str);
              } catch (ex) {

HTH

Alan
Comment on attachment 340837 [details] [diff] [review]
fix ticket-based auth, improve LOGing

>     makeUri: function caldav_makeUri(aInsertString) {
>         var spec = this.calendarUri.spec + aInsertString;
>         if (this.mUriParams) {
>-            return spec + this.mUriParams;
>+            spec += this.mUriParams;
>         }
>         return makeURL(spec);
>     },
...
>-            var headchannel = calPrepHttpChannel(this.calendarUri, null, null,
>+            var headchannel = calPrepHttpChannel(this.makeUri(""), null, null,

I'd prefer  calling makeUri like |this.makeUri()| and then using (aInsertString || "") in the makeUri function.


>         if (this.verboseLogging()) {
>-            LOG("CalDAV: send (Originator=" + organizer +
>-                    ",Recipient=" + mailto_aCalId + "): " + fbQuery);
>+            LOG("CalDAV: POST " + this.outBoxUrl.spec + "\n (Originator=" + organizer +
>+                    ",Recipient=" + mailto_aCalId + "):\n" + fbQuery);
>         }
> 
>         var httpchannel = calPrepHttpChannel(this.outBoxUrl,
>                                              fbQuery,
>                                              "text/calendar; charset=utf-8",
>                                              this);
btw, doesn't the outbox uri also need the ticket parameters?


Also, is ticket based auth fixed for places where we need to ensure a trailing slash? For example, when querying the namespace uris.


r=philipp with comments considered.
Attachment #340837 - Flags: review?(philipp) → review+
(In reply to comment #14)

> I attempted to patch calDavCalendar.js with the previous post. But 6 out of 32
> hunks failed. 

As noted in comment #13, the patch as proposed assumes that the patch proposed in bug 455262 has already been applied, so it won't apply cleanly to the current tree.
(In reply to comment #16)
Ooooops - sorry my bad. I applied both patches in order and they applied cleanly :-) 

Event/Task creation now seems to work again although I haven't carried out extensive testing.

Having been out for a couple of hours, I came back and restarted my computer, the calendar collections loaded (is it me or did they load faster?) fine and I created another test event to verify the patch. Then I tried to remove it.

I can't delete events! Next to the calendar collection name in the left panel, is a small warning triangle and it says "The calendar (name) is momentarily not available". It has now done so for the last 15mins.

When I try to delete my test events I get the following message dialogue:

---------Begin Error Dialogue---------
"An error occurred when writing to the calendar Work (Shared)!

Error Number: MODIFICATION_FAILED
Description:
---------End Error Dialogue-----------

I have re-loaded the calendars but the warning triangle is still there. Even after a cold restart of TB the calendar collection "loads" just fine. The warning triangle does not appear until I try to delete an event. Once I attempt to delete something it then appears and the error dialogue displays as above. The calendar collection with these symptoms has the ?ticket suffix in the URL.

HTH

Alan
Curious. Deletions work fine for me (obviously; wouldn't have submitted the patch if not). Do you see anything in the error console when you try to delete an item? (You'll be able to see more in the error console if you create some extra prefs as Philipp described in comment #7). Do you by any chance have cache turned on?

The triangle simply means that the calendar is currently read-only. You likely can clear that by opening the calendar's properties and clearing the ro checkbox. We may want to reword that message: it can be read as implying that that Lightning will notice when the calendar again becomes writeable, which is not necessarily the case.
(In reply to comment #18)
I have just attempted to delete one of the "test events" I created. It does indeed record some errors in the console.

I do not have local caching turned on.

One thing that may be important. The version of Cosmo we are running is fairly old; it is a 0.12 snapshot from SVN. Although it has worked *perfectly* until the Lightning upgrade to 0.9. (I am loathe to upgrade it at this time as the server it is running on is totally custom built - all from source code - with no easy means to upgrade (no PM). I plan to migrate to a regular distribution at some time in the future but it will be a major exercise to do the upgrade as there are lots more services running on it...)

There are several errors already lurking in the console prior to my delete attempt which don't seem to be related to this problem (I have seen them before) but for completeness here they are first:

Error: No trigger property for alarm on item: -WWW-FONDOO-NET-WEBCAL-ALANBELL-0000000313
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758
Error: No trigger property for alarm on item: 940a3e66-8437-46af-abb8-7c7f7a9d7d0c
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758

Error: No trigger property for alarm on item: 94c03352-96ed-4008-ba4d-4d60cbe23e05
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758

Error: No trigger property for alarm on item: 730d5496-92ad-49fb-a037-f5a7fd988994
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758

Error: No trigger property for alarm on item: e08b54da-87db-40a0-9a8a-ebf69958071b
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758

Error: No trigger property for alarm on item: 1d07bfe2-ff16-4699-9aea-df416a635f64
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758

Error: No trigger property for alarm on item: 040000008200E00074C5B7101A82E00800000000A087C67BE194C8010000000000000000100000004BD900D531BCDE4AA93959DB44FBA79A
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
Line: 758

So the errors above were present *before* I attempted to do the deletion. The errors below occured after I attempted the deletion:

Error: [Exception... "Could not convert JavaScript argument"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js :: calPrepHttpChannel :: line 54"  data: no]
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js
Line: 54

Error: [Exception... "Could not convert JavaScript argument"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js :: calPrepHttpChannel :: line 54"  data: no]
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js
Line: 54

Error: [Exception... "Could not convert JavaScript argument"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js :: calPrepHttpChannel :: line 54"  data: no]
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js
Line: 54

Error: [Exception... "Could not convert JavaScript argument"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js :: calPrepHttpChannel :: line 54"  data: no]
Source File: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js
Line: 54

Error: uncaught exception: [Exception... "Could not convert JavaScript argument"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendarModule.js -> file:///home/alord/.mozilla-thunderbird/tb-profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calProviderUtils.js :: calPrepHttpChannel :: line 54"  data: no]

Needless to say, the deletion was not successful.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
An update: I was about to respond to a comment on the mailing list referencing this bug. I tried add and then delete a new event as above. 

Go figure: It worked. No errors in the console.

Maybe some updates to Intrepid Ibex in the last couple of days have fixed something?

Anyway - using the patches refered to above seem to work. Thanks.
Hm, i just tested the patch, applied the two patches in order, they applied cleanly to the release version of mac sunbird 0.9 and now nothing happens in my sunbird. No calendar events are displayed from the ticketed calendars and no error message is displayed either. Any ideas?

Also a new problem has appeared in the error console:
Error: itemType is not defined
Source File: file:///Applications/Sunbird.app/Contents/MacOS/components/calDavCalendarModule.js -> file:///Applications/Sunbird.app/Contents/MacOS/js/calDavCalendar.js
Line: 1022
Maybe i should add that the patched 0.9 version still prompts me for a password for the ticketed URL whereas 0.8 (which works) doesn't.
i am wondering whether there is any progress or work done regarding the issue i have posted. The patch didn't work for me and i keep having the problem that people in my group who use lightning to access chandler server keep updating lightning accidentally to 0.9 all the time. It is really cumbersome to downgrade lightning again and again.
Benjamin, could you confirm this bug on a recent 1.0pre nightly? Anyway, this needs investigation.
Flags: blocking-calendar1.0+
Hm, trying the current 1.0pre Sunbird now. There is a new error message and i am beginning to wonder whether the problem was related to the Caldav module in the first place. It says that my security certificate is invalid, because it is self-signed (yes, it is!). Error Code: sec_error_ca_cert_invalid. But unlike it is possible in Firefox for example, i am not offered to make an exception for my certificate. Is there any way to work around that check? Then i might be able to test whether this had been the problem in the first place. Is it possible that this error message wasn't displayed in earlier version, but that the connection was simply declared as invalid?
@Benjamin, try this:

- go to Tools/Options(Edit/Preferences)/Advanced/Certificates
- push the 'View Certificates' button
- open the servers tabpage and push 'Add Exception'
- insert the server name and push 'Get Certificate'
- and then 'Confirm Security Exception'

HTH
Here is what i did: in a fresh Windows Virtual Machine with no prior Sunbird configuration, i installed 1.0pre. When i added the certificate manually as Andreas suggested, i could read all calendars with my own account, but not with an account that didn't own the calendar. I think the trouble starts with the fact that sunbird asks for a username and password when it really shouldn't for a ticketed url.

I then wiped the preferences and went back to 0.8. When i added the calendar here, i wasn't prompted for a password which makes sense, because the ticketed url isn't connected to any username and password and should be accessible by the ticket. Sunbird 0.8 still works without any problems. I upgraded to 0.9 and foreign accounts didn't work anymore - it prompted for username and password. I applied once again those two patches in the right order and they didn't solve anything - same behavior as 0.9 without the patches.

It may be noteworthy that even when i logged in with the account who owned the calendar, i could only read the calendars, but 0.9 with patches as well as 1.0pre gave me trouble when i tried to edit or delete events. 0.9 with patches said something MODIFICATION FAILURE (i'm not sure, i don't remember the detailed message) and 1.0pre just didn't react to the save and close button click.

I hope this helps...
I am cc'd on this bug as it has affected me. Just to help in the tracking down, I am using TB version 2.0.0.18 (20081125), Lightning 0.9 (build 2008091718) on Ubuntu Intrepid Ibex.

I did apply the 2 patches mentioned earlier and *most* of the time the operation between Lightning and Cosmo (The Chandler Calendar Server) is fine. I have 6 calendars, 3 of which are accessed using tickets and 3 which are owned by me [the user] on the calendar sever. The ticket based access collections are read-only for me.

Occasionally, when I create a new event or task for one of my collections, it gets written to the Cosmo server, but fails to display in Lightning. But it is quite infrequent. I also have had the MODIFICATION FAILED popup when trying to edit or delete but also now only very occasionally.

We have moved our Cosmo server recently onto a new server and updated to 1.1.0 at the same time. Previously we had been using a 0.12-SNAPSHOT release.
By the way, we are using 1.1.0 version of Chandler Server. Lord Alan, are you accessing the ticketed urls with the user account that owns the calendar or with a different user account? Do you get the username/password popup for the ticketed calendar at all with 0.9? I ask, because if you get the popup, you enter the username and password of the user who owns the ticketed calendar, then the description matches what i have: i can read the calendar, but have problems modifying with the MODIFICAtION FAILED popups you get. I get them quite more frequently. The interesting thing would be what happens when you access the ticketed url with a different user account than the one who owns it. If your system behaves like mine, you won't be able to access it at all and hence, the whole purpose of ticketing urls and calendar sharing is broken (as it is with me).
(In reply to comment #30)
> By the way, we are using 1.1.0 version of Chandler Server. Lord Alan, are you
> accessing the ticketed urls with the user account that owns the calendar or
> with a different user account? Do you get the username/password popup for the
> ticketed calendar at all with 0.9? 

The ticketed collections are owned by other users of Cosmo. Not me. And I do not get asked for username/passwords with the ticketed collections.

Here is the URL I am using for one of the ticketed calendars (domain part mangled for obvious reasons):

http://my-host.cosmo.org/cosmo/dav/ddlord/884e1930-b240-4aec-a0f8-00650cf9a926?ticket=583eqt3r50

> If your system behaves like mine, you won't be able to access it at all and
> hence, the whole purpose of ticketing urls and calendar sharing is broken (as
> it is with me).

Not quite. We can access ticketed collections as expected. Perhaps your URL syntax is incorrect?
Just tried it once more with 0.9+patches, i also tried to access without https, but http as it was the only clear difference that i identified in the structure of the urls. So my urls map exactly to what you have pasted regarding what they look like, https isn't the problem, one of my calendars is also read-only as opposed to read-write. Having it alone didn't change anything. I always get the username/password popup and although i really want to see a mistake on my side, i really don't because everything works with 0.8. I am just a little clueless regarding why it works for you and why it doesn't for me.
There is a lot of information to parse above, I would appreciate if someone could do a very short summary:

* What type of servers are affected (i.e ticket-based only)
* What is needed to fix this bug?
* Bruno, are you still working on this bug?
* Does this block 1.0 ?
I have recently set up my wife's PC (XP SP2) with Thunderbird and Lightning and am having issues connecting to our Cosmo Calendar Server.

Thunderbird: 2.0.0.19 (20081209)

Lightning: 2008091719

Chandler Server Version 1.1.0 

Calendars with a ?ticket=xxxxxxxx suffix are not working on my wife's PC (yet similar ?ticket collections are OK on my Ubuntu Linux Desktop machine). I get the little warning triangle and no calendar data is displayed. The error console in Tb provides the following errors:

Warning: There has been an error reading data for calendar: Al's Work (Read Only).  However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at http://mydomain-private.com:8180/cosmo/dav/collection/9e62fd38-b8b9-11dc-99e8-c27c3db79943?ticket=61e8ca30 is either not a DAV collection or not available

Warning: There has been an error reading data for calendar: Al's Work (Read Only).  However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description: 

And if I try a different collection I get the same errors:

Warning: There has been an error reading data for calendar: Family (Shared).  However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at http://my-private-domain.com:8180/cosmo/dav/alord/60686690-e941-4e5e-871e-2964695258ad?ticket=8b5d9c60 is either not a DAV collection or not available

Warning: There has been an error reading data for calendar: Family (Shared).  However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description: 

I have tried a patched calDavCalendar.js but it doesn't appear to make any difference. 

I am not sure if this is the right place to post this so apologies if it's in the wrong place.

There is a bug with similar errors (https://bugzilla.mozilla.org/show_bug.cgi?id=448453) but it was closed quite a while ago - i.e. before 0.9 was released.
Whiteboard: [not needed beta][no l10n impact]
Whiteboard: [not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs updated patch]
Summary: CalDav calendars disappears after restart → Fix caldav ticket-based authentication
Attached patch Fix - v2 β€” β€” Splinter Review
This is a (manual) update of the last patch. Contains more logging, moves to cal.LOG(), fixes ticket based authentication. I've tested this with https://hub.chandlerproject.org/

The url I used was:

https://hub.chandlerproject.org/dav/collection/2ae3d3e0-0c29-11de-b3ae-a710cf9e86fc?ticket=MYTICKETID
Assignee: browning → philipp
Attachment #340837 - Attachment is obsolete: true
Attachment #366285 - Flags: review?(dbo.moz)
Whiteboard: [not needed beta][no l10n impact][needs updated patch] → [not needed beta][no l10n impact]
(In reply to comment #35)

Thanks for this patch. I will try it out shortly but may I ask first, is it to be applied to a "clean" calDavCalendar.js or does it need either or both of the two earlier patches suggested/created by Bruno?

Thanks
I have tried patching both the original file and my already patched file: The patch fails on either:

With the original source file I get 26 hunks failing and on a pre-patched file I get 46 failures.

I'm in a testing directory with both the target and patch file and using the following command:

patch -Np4 -i 447824v2.patch

Any ideas?
This patch applies cleanly to the latest nightly version of calDavCalendar.js. It may possibly depend on bug 464133's patch, but you should first make sure you are using the latest nightlies (1.0pre with Thunderbird 3.0b2 or 3.0b3pre)
Comment on attachment 366285 [details] [diff] [review]
Fix - v2

looks good; r=dbo
Attachment #366285 - Flags: review?(dbo.moz) → review+
This patch requires the patch from bug 464133 to be checked in.
Depends on: 464133
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/44e354aa73a9>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Hi there,

I do not know if the behaviour I encounter is connected to this bug, but it might be: After downloading the latest 1.0pre of Sunbird, subscribing to my WebDAV calendars does not work anymore. Sunbird is complaining about DAV_NOT_DAV, and my webserver (apache2) is returning error code 400 to the propfind request. The access.log reads:
[23/Mar/2009:22:00:51 +0100] "PROPFIND /xxx/yyy.ics/ HTTP/1.1" 400 226 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090323 Calendar/1.0pre"

That - to me - sounds reasonable, as I think the trailing slash is incorrect (the calendar file is /xxx/yyy.ics). The error.log reads:

[Mon Mar 23 22:00:51 2009] [error] [client 80.187.105.101] Could not fetch resource information.  [400, #0]
[Mon Mar 23 22:00:51 2009] [error] [client 80.187.105.101] (2)No such file or directory: The URL contains extraneous path components. The resource could not be identified.  [400, #0]

Could it be that the ticket-based authentication fix broke something else? Or is it a misconfiguration? Adding PROPFIND to LimitExcept did not solve the problem...

Does anyone have a hint? Or am I just missing something?

Thanks,

fgrassmann
This bug is about caldav ticket based auth, if all you have is an apache server, then you need to use webdav/iCalendar/ics
Bug 536555 is 

> CalDAV: ticket-based access control: DAV_NOT_DAV and READ_FAILED errors
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.