This is the equivalent of #127 (and #140) for CardDAV and finally allows
backends to serve different address books to different users.
While I'm breaking the interface, correct one last instance of
"Addressbook" to "AddressBook" (in `AddressBookHomeSetPath`).
Matches on open time ranges (i.e. no end date) were not properly
handled, as `end` is simply the zero time, which confuses the
`.Before()` and `.After()` logic employed here.
This commit fixes that by adding the appropriate `.IsZero()` checks and
also adds a test case.
The current behavior unfortunately broke compatibility with DAVx5, which
by default queries only events less than 90 days ago (by using an open
time range).
This CL corrects the following bug uncovered by staticcheck:
```
internal/elements.go:148:6: this comparison is always true (SA4023)
internal/elements.go:146:18: the lhs of the comparison gets its value from here and has a concrete type
```
Signed-off-by: Sebastien Binet <binet@cern.ch>
It seems like the Reminders app in iOS/macOS does this request as
the first thing when setting up an account, so it seems reasonable to
handle it for us.
This just returns the most basic current-user-principal now, but that
should hopefully be enough to continue the process.
I started using this project to export tasks over CalDav, more
specifically to Reminders on iOS/macOS. I quickly realized that
even if you specify that `SupportedComponentSet` contains `VTODO`, that
isn't reflected properly when doing the `PROPFIND`.
This patch should fix that, while keeping the behaviour of defaulting to
`VEVENT` for propfind. Also added some tests to make sure that I didn't
break anything (Which I hope I didn't 😅).
This is done properly in the carddav and caldav packages, but the custom
function does not know what the user intends to serve, so it must be
passed in from the user. Without this, certain clients (e.g. DAVx5)
will be unable to discover endpoints served this way.
Also slightly extend the supported methods returned on OPTIONS requests.
REPORT is properly supported, the others are mostly for not giving
clients the impression that the resources are read-only.
The `If-Match` and `If-None-Match` conditional headers can have either a
wildcard or a (quoted) ETag as value. However, the ETag _could_ be a
literal `*`, so care must be taken to allow these cases to be
distinguished. The values of these headers have to be handled by the
backend, so export a type that facilitates working with these values.
The match helper will now properly return recurring events if any of
their recurrences fall into the queried time range. A test for this was
added as well.
See https://www.rfc-editor.org/errata/eid4164
The original RFC's appendix was missing a part of the calendar data used
in the examples. This will become relevant when adding tests for
retrieving recurring events.
As the implementation evolves, it will be necessary to have more tests
to assert we don't break anything when making changes. This commit
introduces a test setup to test that server and client can handle the
address book discovery with various parameters. The test setup should be
easily extendable to cover even more ground as needed.
With this commit, the list of AddressObjects returned by `Filter()` will
always be a correct response to the query argument passed to it, even if
the input list contained objects with arbitraty properties present.
As is, the tests in `match_test.go` test wrong behavior. They request
"partial retrieval" (i.e. filtering of returned properties), but compare
the returned result to the original input. They essentially rely on the
fact that property filtering is currently not implemented.
To fix this, simply make all existing test queries request all
properties. If property filtering gets implemented (correctly), the
tests will then continue to work. New tests can be added for testing
the property filtering itself.
One common method for CalDAV or CardDAV clients to find the current user
principal URL is to request the `/.well-known` URL (see [RFC 6764,
section 6][1]), expecting a redirect. Such URL is for example a valid
result of the discovery phase described in that RFC. The expectation is
that a client, given such URL, is able to find the principal URL by
following a redirect when sending a PROPFIND request.
This change makes `PropfindFlat()` (and, by extension,
`FindCurrentUserPrincipal()`) handle such a redirect and correctly
return the requested properties, even if their HREF is different from
the original request path.
[1]: https://datatracker.ietf.org/doc/html/rfc6764#section-6
This is not yet complete (see TODOs in code), but basic filtering of a
list of CaledarObjects works.
Includes test data from the RFC, which allows to use the RFCs examples
as test cases.
