Skip to documentation content

Security & Privacy

Secure iCal sources and export links

Protect imported feed URLs and per-room export tokens while preserving safe occupancy behavior when a source fails.

Treat an iCal URL like a credential. Imported sources accept HTTPS (with webcal normalized to HTTPS) and reject embedded credentials, fragments, private or reserved hosts, IP literals and unsafe redirects. The source URL is stored with authenticated encryption and a keyed fingerprint for duplicate detection; plaintext, ciphertext and fingerprint are not serializable to an Admin response. Display only a masked origin such as https://host/....

Room export links are bearer links for a controlled RFC5545 feed. The generated token has 32 random bytes, is stored as a one-way hash and is shown only once. Rotate it immediately when exposure is suspected; the old token must return

  1. Exclude the iCal route from page or CDN caching, purge prior edge entries, and redact token paths from access logs. The feed contains sold-out date events, not guest data, prices or remaining quantity.

An iCal fetch is bounded by HTTPS validation, timeout, redirect, byte, event, line and horizon limits. A parse, license or storage failure preserves the last known-good snapshot; it must never release occupancy as a side effect. A valid empty calendar releases only that source’s blocks. External blocks remain read-only and enforced even when Pro is deactivated or its license is lost; existing external blocks therefore remain occupancy authority.

Only staff with hb_manage_channels, a POST request and a valid nonce may mutate a source. Never share a full feed URL in screenshots or support logs.

Was this article helpful?

Your feedback helps us improve the documentation.