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. > > 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" > > 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? > > ===== > > 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?
Attachment
Watch this ticket

Saved Queries