caldav: list every calendar on the account, and read each one ticked

[distronode-com]

What was broken

Connecting a CalDAV account binds one collection, and caldav.ListCalendars reported only that one. The calendar picker is already provider-generic (connection_calendars, Check and Book), but for CalDAV it had exactly one row to show, so an account with several calendars (Synology Calendar in #42) could only be checked and booked through its default calendar.

What it does now

• The picker lists every calendar in the account. ListCalendars repeats discovery from the stored collection URL with the stored credentials: current-user-principal (RFC 5397 defines it on every resource), then calendar-home-set, falling back to the collection's parent when a server answers neither. Every VEVENT-capable collection under the home is listed. A collection with no display name is named by its last path segment, and the bound one is Primary. Writable comes from DAV:current-user-privilege-set (all, write, write-content or bind), and a server that does not report it is treated as writable, as before. The server URL typed at connect is not stored, so starting from the collection avoids a migration. Existing connections work without reconnecting.
• Free/busy reads every calendar ticked for conflicts, per account and fail-open per calendar. Unticked calendars are never read, and free/busy makes no discovery requests. An account that never saved a selection still reads only its bound collection, including one with the single row migration 00049 seeded.
• Writes already followed the chosen Book calendar (DestinationCalendarID). This PR adds tests pinning that a booking lands there and that update and cancel use the stored event URL.
• The picker explains Check and Book in one sentence, including why Book moves rather than unticks (one destination per user across accounts, unchanged).
• A CalDAV 401/403 now unwraps to calendar.ErrReauthRequired, and IsReauthErr recognises the sentinel. Listing is now a network call, so a revoked app password shows as "needs reconnecting" rather than "could not reach the calendar provider". The connect form's message is unchanged.

Two refusals, and why

Both apply to CalDAV only, because a CalDAV calendar id is the URL that free/busy and bookings send the account's Basic credentials to for as long as it stays selected.

1. A collection listed on a different origin (scheme, host, port) from its calendar home is skipped and logged, both at connect and when listing, so an href in a listing cannot point those credentials at another host.

   This changes connecting for one setup. A self-hosted server behind a reverse proxy that reports its internal scheme or host in every href (for example http:// behind a TLS-terminating proxy) used to connect and now does not. For that case connect fails with an error naming the cause, not "no writable calendar found". For example: "the server lists its calendars at a different address (http://nas.lan:5000) than the one Calnode reached it at (https://cal.example.com); check the server's reverse proxy or base URL settings". A server with some calendars on its own origin still connects to those.

2. Saving a selection that names a calendar the server did not list is refused. PUT .../calendars answers 400 with "calendar "…" is not one of this account's calendars. Reload the list of calendars and save again.", and nothing is saved. Before this, the endpoint stored whatever ids the client sent, which for CalDAV meant any URL, skipping both the connect-time URL check and discovery.

   This goes through a new optional interface, calendar.SelectionValidator, which SetAccountCalendars calls (before its transaction opens) only when the provider implements it. CalDAV implements it against its own listing. Google and Microsoft do not, so their saves behave exactly as on main, with no provider call and aliases such as Google's "primary" still accepted. Their ids name calendars inside an API the account's token already scopes, so a check there would add a network call and a new way to fail while protecting nothing; the behaviour change is kept to where the risk is. For CalDAV, a failure to check answers 502 and a rejected login 409, matching the GET.

Every new request goes through the existing metadata-only dial guard; no new SSRF tier is added.

Tests

• internal/caldav/calendars_test.go: an httptest CalDAV account with two VEVENT calendars, a VTODO-only list, a collection whose href is on a second test server (another origin), a read-only calendar (read + write-properties) and privileges reported only under a 404 propstat. It asserts:
  • the listing: names, Primary, Writable, no VTODO list, nothing from the other origin, and zero requests to it;
  • the parent fallback, and that a 401 is a reauth error;
  • free/busy REPORTs hit exactly the selected calendars and nothing else;
  • with no saved selection, and with a 00049-seeded row, only the bound calendar is read;
  • a booking PUT goes to the chosen calendar, and update and cancel use the stored event URL after the destination moves;
  • the VTODO list, the other-origin collection and an unlisted same-origin URL are each refused, with nothing saved;
  • connect against a server whose event calendars are all on another origin fails with the address error and saves nothing, while a server with no event calendar keeps "no writable calendar found";
  • sameOrigin treats default ports as equal and a different scheme, host or port as different.
• internal/calendar/calselect_test.go:
  • a provider that does not implement SelectionValidator saves an unlisted id and "primary" as given, and is never asked to list;
  • an implementing provider's refusal saves nothing and leaves the previous selection intact;
  • a failure to check is ErrCalendarList and still recognisable as a reauth error.
• internal/handler/calendar_caldav_test.go: connect, list and PUT through the real handler and client. An unlisted id gets a 400 with the message, and a listed one a 204.
• Mutation checks, each restored afterwards: disabling the origin filter, the CalDAV id comparison, the service's call to the validator, or the connect-time address error each makes the tests above fail.
• Also run by hand against the built binary with a fake Synology-style server. The picker listed three calendars (read-only Book radio disabled), both bad ids got a 400, and slots excluded busy time from exactly the ticked calendars. The booking was written to the chosen calendar, and nothing reached the other origin.

gofmt -l . clean, go vet ./..., go build ./..., go test ./..., pnpm check and pnpm build all pass.

Deliberately not done

• Book semantics are unchanged: still one destination per user, chosen by radio.
• Connect-time discovery (principal and home hrefs, PROPFIND redirects) still follows the server as it always has, because it starts from the URL the user typed and can legitimately cross hosts (iCloud's calendar home is on a per-account partition host). Listing an existing account's calendars does not: since 294f99d it never sends a request, or follows a principal, calendar home or redirect, off the connected calendar's origin.
• Selections saved through the API before this change are not re-validated when read.
• Writability is not enforced server-side when saving a Book calendar; the picker disables the radio, as it already did.
• No change to which calendar connect binds, apart from the origin rule.

Fixes #42

🤖 Generated with Claude Code

[shockalotti]

Strong PR — this is the correct fix for #42 and the design is careful in the right places: provider-generic SelectionValidator with a stated reason Google/Microsoft are exempt (opaque ids inside an already-authorized API), fail-closed on made-up ids (a CalDAV id is a URL credentials get sent to, so validation is SSRF-adjacent and treated as such), same-origin listing, and a 400/502/409 error taxonomy that tells the user which of 'you picked wrong / provider down / reconnect' applies. Two non-blocking notes pending green CI:

1. Confirm the listing and validation dials go through the same guarded transport (narrow tier) as the rest of the CalDAV client — i.e. no new unguarded dial path was introduced for discovery-from-collection. My read is everything funnels through c.propfind → c.hc.Do, but an explicit yes would close it.
2. Writable counts as true when the server reports no privilege-set (fail-open). Reasonable for servers like Synology that may not report it — failure then surfaces at write time — just noting the direction is deliberate.

[pullfrog]

Important

Listing follows current-user-principal / calendar-home-set from the bound collection without the origin pin used for collection hrefs, so opening the picker can send the app password to another host and then offer that host's calendars to save.

Reviewed changes

CalDAV accounts can list every same-origin VEVENT collection, tick several for free/busy, and refuse saved ids the server did not list.

• Multi-calendar listing — ListCalendars rediscovers the home from the stored collection URL and lists VEVENT collections, with Writable from DAV:current-user-privilege-set.
• Free/busy per tick — conflictConns issues one REPORT per selected calendar; accounts with no saved selection still read only the bound collection.
• SelectionValidator — CalDAV rejects unlisted ids before SetAccountCalendars writes; Google/Microsoft saves stay local. Handler maps unknown / reauth / list-failure to 400 / 409 / 502.
• Connect origin skip — collection hrefs on another origin from the home are skipped; all-foreign event calendars fail connect with an address-mismatch error. PROPFIND 401/403 unwraps to ErrReauthRequired.
• Picker copy — Check vs Book (and read-only) is spelled out on the calendar settings page.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Grok ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes since the last review (d4a055b): listing an existing CalDAV account now stays on the bound collection's origin, which was the remaining credential-leak.

• Principal and home stay put — homeForCalendar no longer follows a current-user-principal or calendar-home-set on another origin from cn.calURL; it lists the bound collection's parent instead.
• Redirects are refused before the hop — listing propfinds take pinOrigin and reject an off-origin Location before credentials go there. Connect still passes "", which is the iCloud / well-known case.
• Listed ids match the bound origin — ListCalendars drops any collection that is not same-origin with the connected calendar, so ValidateSelection cannot accept it.
• The second origin is a real CalDAV account in tests — principal elsewhere, home elsewhere, and a home-listing 301 each assert zero requests to it and that the stolen calendar is not saved.

  ^{｜ View workflow run ｜ Using Grok ｜ 𝕏}

[distronode-com]

Both confirmed.

1. Yes, one guarded transport throughout. The package has exactly three c.hc.Do call sites (do in webdav.go, and getICS/putICS in events.go), and this PR adds none. Listing, selection validation and the per-calendar free/busy REPORTs all go through c.do. c.hc is the client New builds, with MetadataSafeTransport and a CheckRedirect that returns ErrUseLastResponse, and propfind follows each redirect by calling c.do again, so every hop passes the same check. Since 294f99d, listing also refuses any hop off the connected calendar's origin before it is sent.
2. Yes, deliberate. A privilege set the server does not report counts as writable (privilegeSet.canWrite), because that is what every CalDAV calendar was assumed to be before this PR read privileges, and a server that omits the property has given no reason to refuse. A calendar that is really read-only then fails at booking time, as it did before. The one tightening is that write-properties alone does not count, since servers grant it on read-only shares so the sharee can rename or recolour them.

[distronode-com]

Closing this now that c22fcc2 is merged in #57. Reading it against this PR, four things it does not cover, in case they are useful:

• Collections off the account's host are accepted. listLive resolves each href with resolveRef and lists it whatever its origin, and propfind follows redirects to any host with the account's credentials. A collection or redirect on another host then receives the app password on every free/busy REPORT once ticked. This PR pinned listing to the connected calendar's origin (pullfrog's finding on this PR).
• A saved selection is not checked against the server's list. SetAccountCalendars stores whatever ids the client sends, and for CalDAV an id is a URL the password is sent to.
• Every calendar is reported writable. A read-only shared calendar can be picked as the destination and fails at booking time. This PR read DAV:current-user-privilege-set.
• Existing connections list only their bound calendar until reconnected, as your commit notes. This PR rediscovered the home from the stored calendar URL, so nothing needed reconnecting.

Happy to send any of these as a small PR against main if you want them.