Repository navigation
Conversation
tchapi
pushed a commit
to tchapi/postel
that referenced
this pull request
Oct 23, 2026
The backend logs into Davis as "<login>*<app id>" with the key's secret (tchapi/davis#313), like the Dovecot master user, and keeps a copy of the address books in SQLite. Autocomplete reads that copy: a CardDAV request costs ~170 ms on Davis. - the first search fills the cache, then at most every five minutes and after the response, one PROPFIND compares the sync tokens and a changed book is fetched again whole - a book is fetched before anything is dropped, and Davis being away or the key refused leaves the cache as it was - matching ignores case and accents, a word starting with the query ranks first - no Davis configured means no suggestions, nothing else changes The dev Davis runs the app keys branch until it is released, see dev/davis/compose.yaml.
tchapi
enabled auto-merge (squash)
October 24, 2026 15:39
tchapi
pushed a commit
to tchapi/postel
that referenced
this pull request
Oct 24, 2026
The backend logs into Davis as "<login>*<app id>" with the key's secret (tchapi/davis#313), like the Dovecot master user, and keeps a copy of the address books in SQLite. Autocomplete reads that copy: a CardDAV request costs ~170 ms on Davis. - the first search fills the cache, then at most every five minutes and after the response, one PROPFIND compares the sync tokens and a changed book is fetched again whole - a book is fetched before anything is dropped, and Davis being away or the key refused leaves the cache as it was - matching ignores case and accents, a word starting with the query ranks first - no Davis configured means no suggestions, nothing else changes The dev Davis runs the app keys branch until it is released, see dev/davis/compose.yaml.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A service that already authenticated the user elsewhere (SSO in front of a webmail, a scheduler like cal.com) should not have to hold the user's password to read and write their calendars and address books. An admin now creates an app key (dashboard or
davis:app-key:create), scoped to some users or all of them, and the service logs in over Basic as<login>*<app_id>with the key's secret — Dovecot style, because DAV clients only speak Basic.Handled in
AbstractAuthabove the Basic, IMAP and LDAP backends, so it works with everyAUTH_METHOD. The key path never reaches the backend: a wrong secret is refused outright, and a*suffixthat is not an app id is passed to the backend as is. No auto-creation on this path. Secrets are shown once and stored hashed; keys can be revoked or given an expiry.Related: #183 (admin-defined keys, not user self-service)