This release mainly adds app keys: a way for a trusted service to read and write a user's calendars and address books without knowing the user's password. App keys are off by default, so nothing changes for existing instances.
- App keys are off by default. Set
APP_KEYS_ENABLED=trueto turn them on. When they are off, the app keys page, thedavis:app-key:*commands and the app key login are not available at all. - Keys are created and revoked from the new App keys page (in the user menu), or with
bin/console davis:app-key:create,davis:app-key:listanddavis:app-key:revoke <app_id>. - Each key has an explicit scope: a list of usernames, or
*for all users.*does not include admins, because they can read every calendar and address book. To let a key act as an admin, add the admin's username to the scope. - A key can only act as an existing account, with exactly the same username. It never creates an account, even with
*_AUTH_USER_AUTOCREATE. - The secret is shown once at creation and stored hashed. A key can have an expiry date, and can be revoked at any time.
- Davis records which users each key acted as, with the first and last use. You can see it on the App keys page and in
davis:app-key:list. - When you delete a user from the dashboard, Davis removes them from the keys that list them. A key that was only for this user is revoked.
- The Diagnostics page shows whether app keys are on, and how many keys are active.
Important
A key acting as a user has the same access as this user. This includes calendars that other users shared with them, and calendars they are a delegate for. Keep the secret on the server side, never in a browser, and prefer a list of usernames over * when you can.
What's Changed
- Added app keys in #313
- Deleting a user, calendar or address book now also deletes the properties clients stored on it
- Old MD5 passwords are now compared in constant time
- Syncing the birthday calendar stops re-reading the address book for every contact
- Public calendars are checked once per request instead of once per event
How to upgrade
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
There is one new, optional env var:
# Set to true to use app keys (see the README). Off by default.
APP_KEYS_ENABLED=false
Full Changelog: v5.5.1...v5.6.0