Thanks to the latest version of go-webdav, this is now a thing. A lot of
operations (like creating a calendar) are not yet supported. But the
basics work fine. Note that multi-calendar means that different users
can each have their own calenders. Resource sharing is not yet
implemented either.
Includes the adding of a lot of debug logs, as issues are otherwise
pretty hard to figure out. The logging still needs to be made more
consistent, and probably cleaned up a bit in some places.
Using a separate os.Stat() call may result in a race where another
request handler running concurrently creates the file in-between
the os.Stat() call and the os.Create() call.
Use O_EXCL to avoid this situation.
Currently, `QueryCalendarObjects()` simply returns all objects. Now that
`caldav.Filter()` is available upstream, use it to actually filter out
events that do not match the query.
As objects always get written to the path that is their UID, we don't
have to worry about UID conflicts. Unless, the client creates a new
contact, in which case this header should be set.
The filesystem storage backend now implements the required functions to
act as a basic CalDAV server. Some refactoring was done based on the
go-webdav development: introduce a UserPrincipalBackend, a new function
to serve the user principal URL, and more. See this PR for lots of
details: https://github.com/emersion/go-webdav/pull/62
Also adds a simple facility for debug output.
Tighten the regex for valid resources and change the name of the default
address book file so that it is not covered by that regex. This will
prohibit clients from accidentally or maliciously PUTing to that file.
Put strict checks in place to avoid authenticated users accessing files
outside of their actual storage directory. These checks will need
updating if multiple address books are to be supported.
