CalDAV server should block clients from attempting to write new files into Inbox

[wsanchez@…]

4/11/07 9:05 PM Bruce: Today we observed that clients are allowed to write files into the Inbox. That is a client bug. But it would be great if the CalDAV server caught this error too.

[wsanchez@…]

4/12/07 6:35 AM Cyrus Daboo: Strictly speaking the spec does not disallow writing to Inbox. However the utility of that is not clear.

What we can simply do in our case is deny at least DAV:write-content privilege to DAV:all on the Inbox. We should probably do the same for Outbox.

4/12/07 12:00 PM Wilfredo Sanchez: I don't think anyone other than the server itself should be allowed to create a resource in the inbox. I assume the CalDAV spec doesn't require that we allow it, so let's simply decide not to. I vote for denying DAV:all and granting DAV:read and DAV:unbind on the inbox collection, which isn't really own by the user so much as by the server.

On the outbox, I'd removing DAV:all and grant enough privs to do the CalDAV POST operations...

4/12/07 8:22 PM Cyrus Daboo: On Inbox, DAV:read and DAV:unbind are not enough. DAV:write-properties is needed to be able to change the CALDAV:calendar-free-busy-set property, and DAV:write-acl is needed to control the CALDAV:schedule privilege. In theory we might need DAV:lock/unlock once we have LOCK support.

Similar issues with Outbox: at least DAV:write-acl is also needed.

Why don't we simply bypass ACL altogether and just prevent a PUT on Inbox in the same way we prevent MKCOL on calendar collections.

4/13/07 11:00 AM Wilfredo Sanchez: It's slightly trickier; MKCOL happens on the calendar resource, PUT happens on a child of the inbox. I guess we can catch that in locateChild()

4/13/07 5:59 PM Cyrus Daboo: We already special case MKCOL and PUT by looking up the parent and then enforcing restrictions. It would be simple to extend that logic to special case Inbox/Outbox as the parent too.