This commit introduces some helpers so that ETags can be calculated at
the same time that files get read or written. Besides looking nicer, it
should also help reduce lock contention around file access, as files do
not need to be opened twice anymore.
This commit adds read/write locking for individual files, so that
concurrent requests (e.g. to read and write the same file) cannot
interfere with one another.
The locking is not very fine-grained at the moment, and can probably be
improved upon. But it does ensure consistency.
Can be used via `-auth.url=file://`. Only supports bcrypt password
hashes ($2y). Use e.g. `htpasswd -c -BC 14 <filename> <user>` to create
a file. Documentation forthcoming.
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.
Not built by default, but can be added with `go build -tags nullauth`.
Enabled by running tokidoki with `-auth.url null://`. Very useful for
simpler debugging when you don't want manage test accounts with actual
passwords.
The capabilities are added automatically by the default principal path
handlers in the `caldav` and `carddav` packages. However, using the
custom handler, they have to be passed in manually.
These being missing before was a violation of the RFC and the cause for
issues when using e.g. DavX5 client. This is now fixed.
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.
