User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Build ID: 20111008085652 Steps to reproduce: Upgraded from Icedove/iceowl from Debian to Thunderbird/lightning on Ubuntu 11.10. Actual results: All read-only calendars on CalDAV servers (two servers running DAViCal with read-only permissions specified at the server) do not show any events. All worked fine prior to the upgrade. All calendars with write access work fine. Reloading, rechecking the calendars makes no difference. Expected results: All read-only calendars on CalDAV servers should display their events.
Component: General → Provider: CalDAV
OS: All → Linux
Hardware: All → x86_64
Do you see any error messages in Tools > Error Console?
QA Contact: general → caldav-provider
After starting thunderbird: One message: Could not find jar manifest entry 'chrome/en-GB.manifest'. Two errors: Warning: Use of getAttributeNodeNS() is deprecated. Use getAttributeNS() instead. Source File: chrome://messenger/content/messenger.xul Line: 0 Warning: Use of getAttributeNode() is deprecated. Use getAttribute() instead. Source File: chrome://messenger/content/messenger.xul Line: 0 After reloading remote or checking/unchecking: none
Could you enable calendar.debug.log and calendar.debug.log.verbose in the advanced config editor? (Thunderbird Options > Advanced > General > Config Editor) and then restart? You should see more in the error console then.
Indeed, for any one calendar I get this set of messages: First: CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:resourcetype/> <D:owner/> <D:supported-report-set/> <C:supported-calendar-component-set/> <CS:getctag/> </D:prop> </D:propfind> Second: CalDAV: Status 207 on initial PROPFIND for calendar <name> Third: CalDAV: Authentication scheme for <name> is Basic Fourth: CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:C1="http://calendarserver.org/ns/"> <response> <href>/cal/caldav.php/username/calendarname/</href> <propstat> <prop> <resourcetype> <collection/> <C:calendar/> </resourcetype> <owner> <href>/cal/caldav.php/username/</href> </owner> <supported-report-set> <supported-report> <report> <principal-property-search/> </report> </supported-report> <supported-report> <report> <principal-search-property-set/> </report> </supported-report> <supported-report> <report> <expand-property/> </report> </supported-report> <supported-report> <report> <sync-collection/> </report> </supported-report> <supported-report> <report> <C:calendar-query/> </report> </supported-report> <supported-report> <report> <C:calendar-multiget/> </report> </supported-report> <supported-report> <report> <C:free-busy-query/> </report> </supported-report> </supported-report-set> <C:supported-calendar-component-set> <C:comp name="VEVENT"/> <C:comp name="VTODO"/> <C:comp name="VJOURNAL"/> <C:comp name="VTIMEZONE"/> <C:comp name="VFREEBUSY"/> </C:supported-calendar-component-set> <C1:getctag>"0bec667b77f6f22806000cd6301f4a23"</C1:getctag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> Fifth: CalDAV: Collection has webdav sync support Sixth: Adding supported item: VEVENT for calendar: <name> Seventh: Adding supported item: VTODO for calendar: <name> Eighth: CalDAV: send: OPTIONS https://url/cal/caldav.php/username/ Ninth: CalDAV: Unexpected status 403 while querying options <name> If this is related to password issues, I haven't changed any accounts, permissions or credentials and as I said the write access calendars work fine.
Looking at your URL you are using DAViCal. Which version is it. Can you explain how you have configured it. Regards.
Davical Server 1: Davical version report: "Want: 0.9.9.7, Currently: 0.9.9.5" Calendar offers permission to the owner: "Read , Read Current User's Access , Write , Write Metadata , Write Data , Create Events/Collections , Delete Events/Collections" Calendar offers permission for read-only users: "Read , Read Current User's Access" Davical server 2: Davical version report: "You are currently running DAViCal version 0.9.9.4. The database schema is at version 1.2.9." Calendar offers permission to the owner: "all , Read , Override a Lock , Read Access Controls , Read Current User's Access , Write Access Controls , Write , Write Metadata , Write Data , Create Events/Collections , Delete Events/Collections" Calendar offers permission to read-only users: "Read , Read Current User's Access" Basically, each user on the server can change his/her own calendar and view other users' calendars. The permissions have been set individually for users, so no groups are involved. I hope this information is useful. Let me know if something more is required. Thanks.
What is not clear from the above bug report is that Lightning makes some of these PROPFIND requests against different server URLs. I believe the problem stems from the fact that the user has granted permisions to access the *calendar* URL, but at some point in the process Lightning makes an unnecessary PROPFIND request against the calendar owner's principal-URL. At this point DAViCal refuses, which seems reasonable if the owner didn't grant access to their principal-URL (and perhaps they shouldn't, eh?). Lightning then "ZOMG I can has no access" and gives up. A short excerpt of the parallel action from the server's access log should confirm this. I'd really appreciate if you can quote an RFC at me that tells me that DAViCal is wrong to refuse that query too...
Sorry, not a PROPFIND, and it is in the bug report above. The problem is of course the: OPTIONS https://url/cal/caldav.php/username/ which is the request against the: <owner> <href>/cal/caldav.php/username/</href> </owner> from the preceding PROPFIND. This section from RFC4918 (under 5.2 Collection Resources) would seem mildly relevant to the general point, too: Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections. But most importantly, from RFC3744: 3.1. DAV:read Privilege The read privilege controls methods that return information about the state of the resource, including the resource's properties. Affected methods include GET and PROPFIND. Any implementation-defined privilege that also controls access to GET and PROPFIND must be aggregated under DAV:read - if an ACL grants access to DAV:read, the client may expect that no other privilege needs to be granted to have access to GET and PROPFIND. Additionally, the read privilege MUST control the OPTIONS method. <!ELEMENT read EMPTY> So if the calendar owner has not granted the 'read' privilege to their principal-URL, the OPTIONS request must be denied, even if they *have* granted that privilege to a different URL. Basically, I don't understand why Lightning is doing the OPTIONS against the owner in the first place. Anything it can learn there about supported methods or functionality is not guaranteed to apply to the actual calendar collection where it makes all of it's other requests... Regards, Andrew McMillan.
(In reply to Andrew McMillan from comment #8) > Basically, I don't understand why Lightning is doing the OPTIONS against the > owner in the first place. Anything it can learn there about supported > methods or functionality is not guaranteed to apply to the actual calendar > collection where it makes all of it's other requests... Likely "historical reasons". I'm happy to have this changed, but unfortunately its too late in the cycle to do this for 1.0. I'd reconsider if this is a small patch with low risk. Confirming based on Andrew's finding.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Philipp Kewisch [:Fallen] from comment #9) > Likely "historical reasons". I'm happy to have this changed, but > unfortunately its too late in the cycle to do this for 1.0. I'd reconsider > if this is a small patch with low risk. Confirming based on Andrew's finding. Isn't it a bit strange that it worked on Owl and Debian though? If these were "historical reasons", it should not have been working there either. Also, isn't it strange that other users have not complained? I would think that my scenario is pretty common.
There are, of course, other people who have your problem. A common workaround for it (in DAViCal, at least) is to add a default privilege of DAV::read-current-user-privilege-set on each principal. Some versions back DAViCal failed to check for any permissions when responding to OPTIONS, so the visibility of this bug increased when that changed.
Another duplicate of bug 588799. Thanks a lot for your next detailed explanation here Andrew.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 588799
You need to log in before you can comment on or make changes to this bug.