Tickets :: Comment on [#13822] Shared calendar makes CalDAV fail with 500

* Your Email Address
* Spam protection	Enter the letters below: .__ .___.__ . ..__. [__)[__ [ __\|__\|\| \| [__)[___[_./\| \|\|__\|
Comment	>>>> created a 2nd calendar of an user, ticked all permissions for Object >>>> Creator, but nothing else and tried to access it with a webdav client: >>>> >>>> cadaver >>>> 'https://127.0.0.1:443/horde/rpc.php/calendars/dvtest1/calendar~K-O2F29fNvZNnvyNhStU_w1/' >>>> >>>> Message from syslogd@msaj at Jan 27 20:54:32 ... >>>> HORDE: [kronolith] Call to a member function toHash() on boolean >>>> [pid 11253 on line 686 of >>>> "/var/www/horde/kronolith/lib/Application.php"] >>> >>> First of all, this is a CalDAV URL and not a valid WebDAV URL. And >> >> When I use a working calendar with cadaver, I see plenty of ics >> files. When I use this shard calendar, I get a 500 HTTP error. >> >>> then it's exactly what happens if you still use an incorrect CalDAV >>> URL from Kronolith versions earlier than 4.2.3. Are you sure this URL >>> is from a recent Kronolith version? >> >> Well, I re-tested. It is possible that last time I used an existing >> calendar _and_ I used the URL of one user with another user's >> credential. >> >> I now have this calendar >> https://127.0.0.1:1443/horde/rpc.php/calendars/dvtest1/calendar~c6rKd7q_99wt7vMg5tAKwt3/ of user dvtest1 showing up as https://127.0.0.1:1443/horde/rpc.php/calendars/dvtest1/calendar~c6rKd7q_99wt7vMg5tAKwt3/ for >> user >> dvtest2. > > The former is correct, the latter not. Make sure you copy the URL > when logged in as dvtest2. The users have different URLs for the same > calendar. > Is the latter URL the one that throws the 500 with the error message > you posted? That would be expected behavior. > >> These URLs are visible in the GUI of >> kronolith 4.2.11 stable >> webmail 5.2.11 stable >> . Apple iCal does automatically discover the calendar for dvtest2. >> However, on access this URL I get: >> >> "PROPFIND >> /horde/rpc.php/calendars/dvtest2/calendar~c6rKd7q_99wt7vMg5tAKwt3/ >> HTTP/1.1" 500 1018 "-" "Mac_OS_X/10.9.5 (13F1603) CalendarAgent/176.2" > > That would be a correct URL. Does this request generate the same > error in the logs? > >> IMHO, a calendar a user has no permission to should not be discovered. >> If the permissions of "Object Creator" may mean that any user has >> access to the calendar, that all users should be able to query >> (select) the calendar. >> >> On the other hand, shouldn't the client get a 4xx code, probably 404 >> for calendars the user has no permission to? > > They does, usually. > >> This problem has a general nature probably. One calendar is from >> dvtest1 to dvtest2 as read only, (Show and Read). iCal tries to >> update the "acknowledged" status to Horde, but Horde returns 500 as >> well. >> >> "PUT >> /horde/rpc.php/calendars/dvtest2/calendar~n6rEEYYc_Nwej1GIqtXcSck/zgcoDob0mEmtMib3PzVM7Wp.ics HTTP/1.1" 500 2323 "-" "Mac_OS_X/10.9.5 >> (13F1603) >> CalendarAgent/176.2" >> >> Shouldn't this a 404 as well? > > Not a 404 but not a 500 either. Again, is this the same error message > in the logs?
Attachment
Watch this ticket

Saved Queries