Closed Bug 940927 Opened 11 years ago Closed 10 years ago

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

Categories

(Calendar :: Provider: CalDAV, defect)

Lightning 2.6.2
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: althaus.it, Unassigned)

Details

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
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
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.