Package org.exoplatform.caldav.client


package org.exoplatform.caldav.client
  • Class
    Description
    One access control entry of a collection's DAV:acl, as RFC 3744 §5.5 defines it: who it applies to, whether it grants or denies, which privileges, and whether the server lets it be changed (EXO-90253).
    Whom an entry applies to: one of the six forms RFC 3744 §5.5.1 allows.
    The forms of DAV:principal.
    What the server answered to an ACL request (EXO-90253): a claim, never a fact.
    Reads the access control list of a BlueMind calendar through BlueMind's own REST API — the one place its sharing state can be read (EXO-90253).
    One entry of a BlueMind container's access list.
    The server refused the credentials.
    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.
    The server accepted the credentials and refused the write anyway: a 403 on a PUT or a DELETE, which is how a CalDAV server says "this resource is not yours to change".
    The conversation never reached the calendar server: the transport failed outright, or a gateway standing in front of the server answered that it could not reach it either (502, 503, 504).
    One calendar collection as a PROPFIND listed it: everything the sync engine binds a pair on, and nothing it does not need.
    What one discovery walk answers: who the authenticated user is on the server, and where that user's calendars live.
    One calendar object (an .ics resource) as the server answered it.
    A collection's DAV:acl as the server answered it to its owner (EXO-90253), with the two facts that decide whether it may be written back.
    What a resource says it supports, as CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) gathers it: the compliance classes of its DAV header (RFC 4918 §10.1) and the methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of evidence the sharing capability is selected from (EXO-90253).
    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 the server answered to a PROPPATCH — the raw status and the statuses of every propstat that did not grant its property.
    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.
    How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).
    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.