All Classes and Interfaces
Class
Description
The server refused the credentials.
Persistence access to the calendar pairs.
The binding between one eXo calendar and one remote collection, for one user
on one declared server.
The CalDAV protocol, and nothing else: it fetches, it does not decide.
Where a CalDAV conversation is allowed to go: the scheme and authority of
one administrator-declared server, plus the account's base collection path
on it.
The one failure the CalDAV client throws for protocol and transport
trouble: the server unreachable, an answer outside the accepted statuses
of the verb, a body that is not DAV XML, or a target this client refuses
to address.
Admits the DAV verbs through this webapp's Spring Security firewall.
Persistence access to the object mappings.
One event's identity across the two sides: the eXo event, the iCalendar
object it corresponds to, and what was last written or read.
HTTP face of the CalDAV relay:
/caldav/rest/dav/{serverId}/**
forwards DAV requests of the authenticated user to the declared server the
id names, and /caldav/rest/connection/verify probes typed
credentials at connect time.The server-side DAV relay: the browser addresses declared CalDAV servers
through
/caldav/rest/dav/{serverId}/** and this service forwards
each request to the one host the registry row names, injecting the
connected user's stored credentials.Persistence access to the CalDAV server registrations.
A CalDAV server declared by an administrator.
REST access to the CalDAV server registry.
The registry of CalDAV servers a deployment offers its users: what an
administrator declares in the third section of the agenda administration
page.
Maps CalDAV server registrations between their JPA entity and the
credential-free
CaldavServer DTO.Maps calendar pairs and their object mappings between their JPA entities and
the service-layer DTOs, and is the single place hrefs are made canonical.
One calendar collection as a PROPFIND listed it: everything the sync
engine binds a pair on, and nothing it does not need.
One calendar object (an .ics resource) as the server answered it.
CalDAV over the JDK's own HTTP client, modelled line for line on
email-connector's
HttpCardDavClient — the hand-written client that
already works against the same BlueMind that defeated the browser — with
the disciplines the relay established carried over:
registry-only targets — endpoints are minted from the server
registry alone (HttpCalDavClient.endpoint(Long, String)), hrefs resolve against
that endpoint's authority, and a foreign-host href is refused;
no redirects — a declared server must not be able to bounce
this client's credentialed requests to another host, so the transport
never follows a 3xx (which also rules the well-known discovery flow out
by design: discovery starts at the registered base path instead);
explicit timeouts and a bounded body read, both
deployment-tunable;
no auth material anywhere near a log or an exception — every
message names the method and the URI, never a header.
The XML is parsed with doctypes and external entities disabled: the
payload comes from whatever server an administrator declared, which is
still attacker-influenced input, and a stock parser would happily read
files off this machine on its behalf.What an MKCALENDAR answered — deliberately never a boolean "created".
What a conditional PUT answered.
Which incremental-sync tier a collection's server can serve, read from one
Depth:0 PROPFIND (
supported-report-set, ctag, sync token) plus the
DAV response header.The incremental strategies of the plan, cheapest first.
What an RFC 6578 sync-collection REPORT answered: the hrefs that changed,
the hrefs that are gone, and the token to store for the next run.