Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
CalDAV server should block clients from attempting to write new files into Inbox #127
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.
Since there is no storage for inbox in the new data store, this should now be impossible