Test 0555 issues an open-ended calendar-query
(<time-range start="20090827T120000Z"/>, no end). Its expected result
had baked in the previous buggy behaviour: two events dated 2011-10
(0544-gzip-PUT.ics and 0545-deflate-PUT.ics) were absent because they
fall beyond the former expand_range_end cap of start + 730 days
(2011-08-27), even though an absent end means +infinity (RFC 4791 §9.9)
and both events match the range.
With the fix they are correctly returned, so the fixture now includes
both responses. This test thus doubles as the regression test for the
fix.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A calendar-query REPORT whose <C:time-range> has a start but no end
(RFC 4791 section 9.9: an absent end means +infinity) dropped every event
whose next occurrence fell beyond time_range_start + 730 days: future
single events and sparse recurrences (e.g. FREQ=YEARLY;INTERVAL=4).
Clients such as DAVx5 send exactly this shape when they limit how far
into the past they sync, so those events silently disappeared.
The SQL prefilter is not at fault: for an open range it correctly emits
only the lower-bound condition. The drop happens in the post-fetch loop:
for any time-range query each resource is expanded into
[expand_range_start, expand_range_end] and skipped when the expansion is
empty (ComponentCount() == 0). For an open range expand_range_end is
capped at start + 730 days, so an event with no instance inside that cap
is discarded even though the preceding
getVCalendarRange()->overlaps($range_filter) test -- which treats a null
upper bound as +infinity -- already proved that it matches.
This became user-visible in 1.1.12: commit b40c96de ("If time-range is
set, only return matching events.") extended the empty-expansion skip,
previously reached only for explicit <C:expand> requests, to every
time-range query via isset($range_filter).
Only enforce the empty-expansion skip when the upper bound is real
(range_filter->until is set) or the client explicitly requested expansion
(need_expansion). For an open range the exact overlaps() test above stands
and the unexpanded master component is returned as normal. Bounded and
<C:expand> queries are unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
iPhone devices incorrectly implement DAV:current-user-principal from
RFC 5397. They assume that current-user-principal is the href for the
resource being queried. The RFC says it should be the current resource.
See: https://gitlab.com/davical-project/davical/-/issues/335
HTTP/2 requests to Davical with debug mode result in logged
Authorization header as the comparison is currently case sensitive
https://datatracker.ietf.org/doc/rfc9113/
> 8.2. HTTP Fields
> Field names MUST be converted to lowercase when constructing an HTTP/2
message.
We also use a locally set password (aka a pepper) to ensure that the contents
of memcached isn't sufficient to perform dictionary attacks on the cached
credentials.
This is intended to reduce the load on external authentication sources
as most (all?) CalDAV clients use HTTPBasicAuth to authenticate and
if an external source is used, every request we receive requires
external authentication. This can place a large load on those external
sources.
Closes#254.
This tickles a bug as reported by Thorsten Marquardt in
https://sourceforge.net/p/davical/mailman/message/58766531/ with this
error message reported:
Exception [0] ldap_get_attributes(): Argument #2 ($entry) must be of
type LDAP\ResultEntry, false given
At line 718 of /usr/share/davical-master/inc/drivers_ldap.php
You need to look in 3da860e5d5e732c2dedb62a73c76608a2b7098a4 for that line
number as I've just made some improvements to the code the last few commits.
This is to tickle my suspicion of the bug as reported by Thorsten Marquardt
in https://sourceforge.net/p/davical/mailman/message/58766531/ with this
error message reported:
Exception [0] ldap_get_attributes(): Argument #2 ($entry) must be of
type LDAP\ResultEntry, false given
At line 718 of /usr/share/davical-master/inc/drivers_ldap.php
You need to look in 3da860e5d5e732c2dedb62a73c76608a2b7098a4 for that line
number as I've just made some improvements to the code.
I have also improved the SQL to check if the users have been added, and
discovered that the result file *did not* have them. This test was failing
due to the test config file looking for memberUid, not member. Also, fix
that.
Add a new value for i_use_mode_kerberos: "allow_fallback_ldap_auth",
which will fallback to username/password authentication when the
REMOTE_USER value is unset.
