Calendar stops working after denied request to principal URL while fetching collections

RESOLVED INVALID

Status

Calendar
Provider: CalDAV
RESOLVED INVALID
5 years ago
4 years ago

People

(Reporter: Matthias Althaus, Unassigned)

Tracking

Lightning 2.6.2

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

We're using DAViCal as a calendar server for ~500 servers. 

Calendar setup is like:
User A creates a collection "foo" and grants user B read access. This way B is allowed to access the collection at the location "http://example.org/caldav/user.a/foo"

Steps to reproduce:
1. Create new CalDAV calendar as user B with the above URL as its location.
2. Enter credentials.


Actual results:

A yellow warning sign next to the calendar name shows up and no calendar data is loaded at all.

Based on the server logs you can see that Lightning does the following steps:

1. :PROPFIND /caldav/user.a/foo/ - Reply status is 207
2. :OPTIONS /caldav/user.a/ - Reply status is 403

If I trick around and get the OPTIONS request to be valid, he tries a PROFIND at the same location which fails too. Based on the 403 Lightning seems to think that he is not allowed to access the calendar at all although only access to the *principal* is denied and he has valid access to the *collection*.




Expected results:

Lightning should not try to access the principal or ignore the denied access at that location and continue with fetching the calendar data from the collection location.

This is the same issue reported in a comment of #588799 (regarding Lightning 1.5) [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=588799#c66
(Reporter)

Comment 1

5 years ago
Damn... after some more debugging I found an issue on the server side which broke the XML reply somehow. Sorry for that. So it's basically working, but I still need to grant the user A the "read-current-user-privilege-set" on the principal of user B.
So this is a server issue, right? If I misunderstood, feel free to reopen.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.