536555 - CalDAV: ticket-based access control: DAV_NOT_DAV and READ_FAILED errors

Status: RESOLVED WORKSFORME

(Calendar :: Provider: CalDAV, defect, P4)

Description

[Graham Perrin]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0

Major bug 447824

> Fix caldav ticket-based authentication

was resolved fixed in March 2009 but I can't get Lightning CalDAV to work with tickets. 

Reproducible: Always

Steps to Reproduce:
1. in Chandler Hub, choose the disclosure triangle for a collection that you own

2. choose Invite (ignore the first appearance of the CalDAV button)

3. choose View and Edit

4. now, choose the blue CalDAV button

5. copy the address of the collection (this includes the ticket)

6. close the dialogue

---

7. in Thunderbird/Lightning add a calendar, on the network

8. choose CalDAV

9. in the Location: field, paste the address of the collection

10. enter a friendly name for the collection

11. choose Continue
Actual Results:  
A yellow exclamation mark appears alongside the calendar. 

Error console offers two warnings (in the example below, the ticket is obscured):

Warning: There has been an error reading data for calendar: G22.  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/af0b5370-ea4d-11de-86e7-ad6bd9dcb7da?ticket=****** is either not a DAV collection or not available

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

The exclamation mark may disappear, but the calendar fails to populate. 

Expected Results:  
Read and write (view and edit) access to the collection on Chandler Server

Using the 22-Dec-2009 09:57 PST build of Lightning. 

Chandler Hub 
Version 1.1-SNAPSHOT-r7367-2009-02-13T13:15

Comment 1

[Bruno Browning]

Looks like we are inserting an extraneous / between the base and ?ticket= portions of the URI. I'm not sure whether or not that is what is causing Chandler Hub to respond with a 500 error to the initial PROPFIND, since I get the same response when I eliminate the /. So this is at least partly a server-side problem.

AFAIK Cosmo is the only CalDAVish server impl that supports ticket-based-auth. Cosmo was written against a pre-RFC4791 version of the spec and is no longer under active development: for all intents and purposes Chandler Hub is the last instance standing. While I'd be happy to see a patch I don't think this should block 1.0.

Comment 2

[Graham Perrin]

Thanks. OSAF Cosmo bug <https://bugzilla.osafoundation.org/show_bug.cgi?id=12691> is

> DAV_NOT_DAV error in response to Lightning and Sunbird 0.9 attempts to subscribe using CalDAV

Comment 3

[Graham Perrin]

Seems to be fixed in Cosmo, <https://bugzilla.osafoundation.org/show_bug.cgi?id=12691#c9> so I guess that it should be INVALID here in the Mozilla area.

Comment 4

[Leho Kraav (:macmaN @lkraav)]

something is broken again with 1.0b2.

ssl_access_log for one of the calendars:

192.168.1.104 - - [29/Jun/2010:01:45:31 +0300] "PROPFIND /chandler/dav/collection/xxxxxxxx-3e45-11df-xxxx-f6e4cd0ed970/?ticket=b8dbead0 HTTP/1.1" 403 303 "-" "Mozilla/5.0 (Mac
intosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1"
192.168.1.104 - - [29/Jun/2010:01:45:33 +0300] "OPTIONS /chandler/dav/collection/?ticket=b8dbead0 HTTP/1.1" 404 140 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1"

colletion id disappears from the OPTIONS request. is this bug relevant?

http://weblogs.mozillazine.org/calendar/2010/06/lightning_10_beta_2_finally_re.html comments has at least one person reporting same behavior.

Comment 5

[Leho Kraav (:macmaN @lkraav)]

during a debugging session on irc with simon_at_orcl i discovered the following:

 * beta 2 does OPTIONS requests for what simon called "calendar home sets", beta 1 does not. this request is the one failing in the above log, because the collection id part is cut out of the request url string.

 * cosmo is capable of handing out calendar urls in two forms:
  - /chandler/dav/collection/xxxxxxxx-3e45-11df-xxxx-f6e4cd0ed970/?ticket=<ticket_id> (main calendar screen, left sidebar)
  - /chandler/dav/<username>/?ticket=<ticket_id> (account browser, ticket list)
  - my failing calendars are all in /collection/ url form. using /chandler/dav/<username>/<collection_id>/?<ticket_id> form makes the calendar appear and work again.

during this whole debugging session (on OS X) i also noticed some more faulty behaviors, which hopefully noone minds if i just note them down here for now:

 * occasionally after creating a new network calendar that could not be loaded, it made the currently open view lose all calendar entries, while sidebar stayed intact. switching to another view (i.e. month -> multiweek) displayed items. switching back, everything empty again. very difficult to tell exactly what conditions this can be reliably reproduced. might be that you need to add more than one non-loadable network calendars.

 * endless loop of PROPFIND requests can be achieved by adding a non-loadable CalDAV calendar and then doing Reload all calendars. server immediately gets seemingly endlessly hammered, i quit thunderbird after about 30 seconds of constant stream of requests. i'm pretty sure i've seen this before beta 2.

Comment 6

[Leho Kraav (:macmaN @lkraav)]

i have now discovered that it is not possible to add new events into the calendars subscribed with /chandler/dav/<username>/<collection_id>/ urls. these calendars simply do not appear in the New Event calendar dropdown box.

yet if i doubleclick an existing event to edit, it seems to succeed and to be saved correctly. calendar name to which the edited event belongs to, does appear in the dropdown box.

Comment 7

[Graham Perrin]

A ticket that allows me to add a calendar, then add or edit events in Sunbird 1.0b1, 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091211 Sunbird/1.0b1

is not accepted by Lightning 1.0b2, 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4

— after clicking 'Done' in the add calendar routine, the calendar is listed (at left) but not populated (at right).

Comment 8

[Graham Perrin]

(In reply to comment #6)

> … edit, it seems to succeed and to be saved

Use an alternative client to verify success. AFAIR there's a separate Mozilla bug that causes some types of addition/edit to *appear* successful, when they are *not* successful.

Comment 9

[Graham Perrin]

>> DAV_NOT_DAV and READ_FAILED errors

(In reply to comment #4)

> something is broken 

(In reply to comment #5)

> a debugging session on irc with simon_at_orcl 

> more faulty behaviors

@Leho

Do you see DAV_NOT_DAV or READ_FAILED?

Comment 10

[Graham Perrin]

>> CalDAV: ticket-based access control …

Whatever's going on in Lightning 1.0b2 is not limited to tickets. I'll close again this bug 536555, 
— RESOLVED
— WORKSFORME
(it *did* work for me on 2010-02-16).  

----

Move along please to bug 599635, 
'DAV_NOT_DAV and error reading data'
— with attention to the 'See Also:' area of the page.