tchapi/davis v5.5.0 on GitHub

This is a minor releases covering a wide span of bug fixes and features to harden Davis and make it even more robust and resilient to various clients' behaviors and auth provider shenanigans.

⚠️ Read the changelog and the "How to upgrade" section below carefully

📰 Main new features or changes

✨ New page: Diagnostics, at /dashboard/diagnostics (#297) to ease debugging and find misconfigurations (migrations you have not run, mail settings, DAV endpoint URL, timezone configuration, etc ...)
✨ New command: php bin/console davis:mail:test you@example.org (#296). Sends one message with the actual mail settings to test them
🔒 The shared directory is no longer writable by every account (#285). Any signed-in user can read it. Only admins can write, unless you set WEBDAV_PUBLIC_DIR_WRITABLE=true. See the upgrade note below.
🐛 Events are saved even when there is a failure sending invitations (#296)
🔒 An account cannot be saved without an email address (#296). An empty address quietly stops every invitation from that account. See the upgrade note below.
🔤 LDAP is no longer case-sensitive for usernames (#289). Davis now uses the spelling the directory returns. See the upgrade note below.
💪🏼 Frontend better validation and hardening (CSRF, CSS injection) (#290, #295)

🐛 Other bug fixes

CardDAV sync no longer loses changes and sync reports are much faster (#287) (based on @AnnoyingTechnology's work)
Saving a property no longer fails or adds up rows (#288)
Address books can be created without a name (#286) (Turns out the name is optional in CardDAV)
Subscribing to a calendar feed no longer fails when clients don't send default (#286)
The API answers when no key is set (API_KEY is empty by default) (#298)
The profiler no longer runs in production (#284)
Fix edge cases where a public calendar was not readable by everyone (#298)
Deleting an address book no longer crashes (#298)

⚙️ Misc

Docker images now use PHP 8.4 (#299), up from 8.3.
nginx and Caddy examples improvements and Dockerfile and env refactors to harden production and dev setup (#292)
/.well-known/caldav and /.well-known/carddav are now handled by Davis (#289) - No web server rule is needed, and it allows sub directories
Added logs on sending invitations to debug more easily (#296)
Repeated failed logins are throttled now (#292)
Performance improvements (new SAPI, allowing streaming responses) (#300)

How to upgrade

Important

The WebDAV folders are now checked at start-up: they must be absolute, exist, and sit outside the web root. Fix them before upgrading, if needed.

0. Back up your database

This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.

1. Update the code and migrate

You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:

bin/console doctrine:migrations:migrate --allow-no-migration

2. Update or add necessary env vars

WebDAV shared directory (only if `WEBDAV_ENABLED=true`)

Important

This is a change of behavior, read carefully

If you relied on the shared directory being writable by everyone, add:

WEBDAV_PUBLIC_DIR_WRITABLE=true

Otherwise only admins can write there from now on. Everyone can still read it in any case

3. LDAP accounts stored under a different spelling

Tip

Only if you use LDAP: AUTH_METHOD=LDAP on PostgreSQL or SQLite. MySQL and MariaDB compare text without regard to case so you can ignore

What changed. Davis used to store whatever username the person typed. It now stores the spelling your directory returns. So if someone logged in as ALICE and your directory says alice, Davis used to create the account as ALICE, and from now on it looks for alice.

What you would see. That person logs in fine but their calendars and contacts are gone — the data is still there, filed under the old spelling. If they typed their name two different ways over time, you may also have two accounts for them, one of them empty.

Find out if you are affected. Both lists should contain each person once, spelled the way your directory spells them:

SELECT username FROM users ORDER BY username;
SELECT uri FROM principals WHERE uri NOT LIKE '%calendar-proxy%' ORDER BY uri;

If a person appears twice, delete the empty account from the dashboard first, then follow the rename below for the one that kept the data.

To rename an account, back up your database, then run the block below. Replace ALICE with the spelling currently stored and alice with the spelling your directory returns

BEGIN;
UPDATE users                 SET username     = 'alice'            WHERE username = 'ALICE';
UPDATE principals            SET uri          = replace(uri, 'principals/ALICE', 'principals/alice')        WHERE uri = 'principals/ALICE' OR uri LIKE 'principals/ALICE/%';
UPDATE calendarinstances     SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE addressbooks          SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE calendarsubscriptions SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE schedulingobjects     SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE propertystorage       SET path = replace(path, 'calendars/ALICE/', 'calendars/alice/')       WHERE path LIKE 'calendars/ALICE/%';
UPDATE propertystorage       SET path = replace(path, 'addressbooks/ALICE/', 'addressbooks/alice/') WHERE path LIKE 'addressbooks/ALICE/%';
UPDATE propertystorage       SET path = replace(path, 'principals/ALICE', 'principals/alice')       WHERE path LIKE 'principals/ALICE%';
COMMIT;

The principals line also renames that person's two delegation entries, so you do not need to touch those separately. Run the two SELECTs again afterwards to confirm.

4. Accounts without an email address

An account whose email is empty never sends invitations (but it was hard to debug properly). The dashboard now refuses to save one, but existing accounts are untouched. To find all of the offending accounts:

SELECT uri, email FROM principals WHERE email IS NULL OR email = '';

The address has to be the one the account's calendar client sends as the event organiser, otherwise Davis has nothing to send an invitation on behalf of. You can check the mail settings themselves with php bin/console davis:mail:test you@example.org.

5. Web server configuration

If your web server rewrites /.well-known/caldav or /.well-known/carddav itself, you can drop those rules. They take precedence over Davis and will send clients to the wrong place on a sub-directory installation.

6. Reverse proxy on a PHP built without IPv6

If your PHP was built with --disable-ipv6 and you set SYMFONY_TRUSTED_PROXIES, your proxy has to reach Davis over IPv4 or every request returns a 500. Point it at 127.0.0.1 rather than localhost, which usually resolves to ::1 first. See the README for details.

Full Changelog: v5.4.4...v5.5.0