davis davis does not work with with php 8.4+ because of the imap removal from core

Update

Future bug divers, here is the comment explaining the issue: https://github.com/tchapi/davis/issues/195#issuecomment-2866750216

Last known working version: 4.4.3
Current version: 5.0.2

Problem

DavX on my android devices are failing to sync calendars and address books, while Thunderbird for the same user and resources, is working fine.

I use imap authentication, and I've double checked that my auth details are correct in DavX.

Call to undefined function Sabre\DAV\Auth\Backend\imap_open()

Here is the debug info from davx (slightly redacted)

--- BEGIN DEBUG INFO ---

NOTIFICATION TIME
Local time: 2025-05-06T15:42:48+02:00
UTC: 2025-05-06T13:42:48Z

SYNCHRONIZATION INFO
Account: Account {[email protected], type=bitfire.at.davdroid}
Authority: com.android.calendar

EXCEPTION
at.bitfire.dav4jvm.exception.HttpException: HTTP 500 Internal Server Error
        at at.bitfire.dav4jvm.DavResource.checkStatus(DavResource.kt:3)
        at at.bitfire.dav4jvm.DavResource.checkStatus(DavResource.kt:1)
        at at.bitfire.dav4jvm.DavResource.processMultiStatus(DavResource.kt:2)
        at at.bitfire.dav4jvm.DavResource.propfind(DavResource.kt:77)
        at at.bitfire.davdroid.sync.CalendarSyncManager.queryCapabilities$lambda$3(CalendarSyncManager.kt:30)
        at at.bitfire.davdroid.sync.CalendarSyncManager.$r8$lambda$WgZpb3kEDaQ7fxdsisoeL5kAHSU(CalendarSyncManager.kt:1)
        at at.bitfire.davdroid.sync.CalendarSyncManager$$ExternalSyntheticLambda8.invoke(R8$$SyntheticClass:3)
        at at.bitfire.davdroid.sync.SyncException$Companion.wrapWithRemoteResource(SyncException.kt:6)
        at at.bitfire.davdroid.sync.CalendarSyncManager.queryCapabilities(CalendarSyncManager.kt:16)
        at at.bitfire.davdroid.sync.SyncManager.performSync(SyncManager.kt:70)
        at at.bitfire.davdroid.sync.CalendarSyncer.syncCollection(CalendarSyncer.kt:10)
        at at.bitfire.davdroid.sync.CalendarSyncer.syncCollection(CalendarSyncer.kt:1)
        at at.bitfire.davdroid.sync.Syncer.syncCollectionContents$davx5_ose_4_4_9_oseRelease(Syncer.kt:44)
        at at.bitfire.davdroid.sync.Syncer.sync$davx5_ose_4_4_9_oseRelease(Syncer.kt:42)
        at at.bitfire.davdroid.sync.Syncer.invoke(Syncer.kt:144)
        at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.invokeSuspend$lambda$0(BaseSyncWorker.kt:1)
        at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.$r8$lambda$MnrEU1_WtQZTTPjmMRztfG3Y7fo(BaseSyncWorker.kt:1)
        at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2$$ExternalSyntheticLambda0.invoke(R8$$SyntheticClass:3)
        at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invokeSuspend(Interruptible.kt:58)
        at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invoke(Interruptible.kt:13)
        at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndspatched(Undispatched.kt:17)
        at kotlinx.coroutines.BuildersKt.withContext(Unknown Source:45)
        at kotlinx.coroutines.InterruptibleKt.runInterruptible$default(Interruptible.kt:9)
        at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.invokeSuspend(BaseSyncWorker.kt:332)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:9)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:115)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
        at java.lang.Thread.run(Thread.java:1012)
HTTP REQUEST
Request{method=PROPFIND, url=https://dav.mydomain.com/dav/calendars/[email protected]/default/, headers=[Depth:0, User-Agent:DAVx5/4.4.9-ose (dav4jvm; okhttp/4.12.0) Android/15, Accept-Language:en-US, en;q=0.7, *;q=0.5, Accept-Encoding:br,gzip, Authorization:Basic redactedQ==]}
<?xml version='1.0' encoding='UTF-8' ?><propfind xmlns="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav" xmlns:CARD="urn:ietf:params:xml:ns:carddav"><prop><CAL:max-resource-size /><supported-report-set /><n0:getctag xmlns:n0="http://calendarserver.org/ns/" /><sync-token /></prop></propfind>

HTTP RESPONSE
Response{protocol=http/1.1, code=500, message=Internal Server Error, url=https://dav.mydomain.com/dav/calendars/[email protected]/default/}
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:sabredav-version>4.6.0</s:sabredav-version>
  <s:exception>Error</s:exception>
  <s:message>Call to undefined function Sabre\DAV\Auth\Backend\imap_open()</s:message>
</d:error>


REMOTE RESOURCE
https://dav.mydomain.com/dav/calendars/[email protected]/default/

SOFTWARE INFORMATION

┌─────────────────────────────────────────┬─────────────────────────────────────────────────┬────────────┬─────────────────────┬───────┐
│ Package                                 │ Version                                         │ Code       │ Installer           │ Notes │
├─────────────────────────────────────────┼─────────────────────────────────────────────────┼────────────┼─────────────────────┼───────┤
│ at.bitfire.davdroid                     │ 4.4.9-ose                                       │ 404090001  │ org.fdroid.fdroid   │       │
│ com.android.providers.contacts          │ 15                                              │ 35         │ —                   │       │
│ com.android.providers.calendar          │ 15                                              │ 35         │ —                   │       │
│ com.google.android.calendar             │ 2025.16.0-749613736-release                     │ 2017747407 │ com.android.vending │       │
│ ws.xsoh.etar                            │ 1.0.48                                          │ 48         │ org.fdroid.fdroid   │       │
│ com.google.android.apps.messaging       │ messages.android_20250422_03_RC01.phone_dynamic │ 276717063  │ com.android.vending │       │
│ com.google.android.googlequicksearchbox │ 16.16.43.sa.arm64                               │ 301507779  │ com.android.vending │       │
└─────────────────────────────────────────┴─────────────────────────────────────────────────┴────────────┴─────────────────────┴───────┘
SYSTEM INFORMATION

Android version: 15

Here are davis logs

[2025-05-06T16:10:50.246235+02:00] request.INFO: Matched route "dav". {"route":"dav","route_parameters":{"_route":"dav","_controller":"App\\Controller\\DAVController::dav","path":"calendars/[email protected]/default/"},"request_uri":"https://dav.mydomain.com/dav/calendars/[email protected]/default/","method":"PROPFIND"} []
[2025-05-06T16:10:50.264559+02:00] security.DEBUG: Checking for authenticator support. {"firewall_name":"main","authenticators":1} []
[2025-05-06T16:10:50.264577+02:00] security.DEBUG: Checking support on authenticator. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
[2025-05-06T16:10:50.264583+02:00] security.DEBUG: Authenticator does not support the request. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
[2025-05-06T16:10:50.382168+02:00] app.ERROR: [500]: Error - Call to undefined function Sabre\DAV\Auth\Backend\imap_open() [{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/src/Services/IMAPAuth.php","line":54,"function":"imapOpen","class":"Sabre\\DAV\\Auth\\Backend\\IMAP","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Backend/IMAP.php","line":80,"function":"imapOpen","class":"App\\Services\\IMAPAuth","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php","line":103,"function":"validateUserPass","class":"Sabre\\DAV\\Auth\\Backend\\IMAP","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Plugin.php","line":179,"function":"check","class":"Sabre\\DAV\\Auth\\Backend\\AbstractBasic","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Plugin.php","line":135,"function":"check","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Server.php","line":456,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/src/Controller/DAVController.php","line":332,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/symfony/http-kernel/HttpKernel.php","line":178,"function":"dav","class":"App\\Controller\\DAVController","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/symfony/http-kernel/HttpKernel.php","line":76,"function":"handleRaw","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/symfony/http-kernel/Kernel.php","line":185,"function":"handle","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/public/index.php","line":33,"function":"handle","class":"Symfony\\Component\\HttpKernel\\Kernel","type":"->"}] []
[2025-05-06T16:10:50.566516+02:00] request.INFO: Matched route "dav". {"route":"dav","route_parameters":{"_route":"dav","_controller":"App\\Controller\\DAVController::dav","path":"addressbooks/[email protected]/default/"},"request_uri":"https://dav.mydomain.com/dav/addressbooks/[email protected]/default/","method":"PROPFIND"} []
[2025-05-06T16:10:50.567157+02:00] security.DEBUG: Checking for authenticator support. {"firewall_name":"main","authenticators":1} []
[2025-05-06T16:10:50.567171+02:00] security.DEBUG: Checking support on authenticator. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
[2025-05-06T16:10:50.567178+02:00] security.DEBUG: Authenticator does not support the request. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
[2025-05-06T16:10:50.572390+02:00] app.ERROR: [500]: Error - Call to undefined function Sabre\DAV\Auth\Backend\imap_open() [{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/src/Services/IMAPAuth.php","line":54,"function":"imapOpen","class":"Sabre\\DAV\\Auth\\Backend\\IMAP","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Backend/IMAP.php","line":80,"function":"imapOpen","class":"App\\Services\\IMAPAuth","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php","line":103,"function":"validateUserPass","class":"Sabre\\DAV\\Auth\\Backend\\IMAP","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Plugin.php","line":179,"function":"check","class":"Sabre\\DAV\\Auth\\Backend\\AbstractBasic","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Plugin.php","line":135,"function":"check","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Server.php","line":456,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/src/Controller/DAVController.php","line":332,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/symfony/http-kernel/HttpKernel.php","line":178,"function":"dav","class":"App\\Controller\\DAVController","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/symfony/http-kernel/HttpKernel.php","line":76,"function":"handleRaw","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/vendor/symfony/http-kernel/Kernel.php","line":185,"function":"handle","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->"},{"file":"/nix/store/679xdyqr4dp3hrxfhfwykghhhbkrs4pp-davis-5.0.2/public/index.php","line":33,"function":"handle","class":"Symfony\\Component\\HttpKernel\\Kernel","type":"->"}] []

Meanwhile my nginx logs show this:

{"time": "2025-05-06T15:54:12+02:00","remote_addr": "","x_forwarded_for": "10.9.6.17","remote_user": "[email protected]","bytes_sent": 596,"request_time": 0.013,"status": 500,"vhost": "dav.mydomain.com","request_proto": "HTTP/1.1","path": "/index.php","request_query": "","request_length": 791,"duration": 0.013,"method": "PROPFIND","http_referrer": "","http_user_agent": "DAVx5/4.4.9-ose (dav4jvm; okhttp/4.12.0) Android/15","upstream_addr": "unix:/run/phpfpm/davis.sock"}

May 06 '25 14:05 Ramblurr

Hi @Ramblurr

Are you using the docker container (which one?) or your own setup (which version of PHP?)

May 06 '25 19:05 tchapi

It's very weird that the error be Error - Call to undefined function Sabre\DAV\Auth\Backend\imap_open() (it's in sabre/dav code btw) — I don't see how this could work with one client, but not another 🤯

Are you sure both clients are hitting the same server?

May 06 '25 19:05 tchapi

Are you using the docker container (which one?) or your own setup (which version of PHP?)

I'm using the nixos distro package with PHP 8.4.6 (php-fpm).

I don't see how this could work with one client, but not another 🤯

Indeed, and it turns out I was wrong! It is also not working on the other client, thunderbird (TB). I see the same errors in the davis/symfony log when TB tries to sync. TB is just not giving me any error messages.

This is my env:

ADMIN_LOGIN="admin"
ADMIN_PASSWORD=redacted
APP_CACHE_DIR="/var/lib/davis/var/cache"
APP_ENV="prod"
APP_LOG_DIR="/var/lib/davis/var/log"
APP_SECRET=redacted
APP_TIMEZONE="Europe/Berlin"
AUTH_METHOD="IMAP"
CALDAV_ENABLED=true
CARDDAV_ENABLED=true
DATABASE_DRIVER="postgresql"
DATABASE_URL="postgres://davis@localhost/davis?host=/run/postgresql"
IMAP_AUTH_URL="{imap.redacted.com:993/imap/ssl/readonly}"
IMAP_AUTH_USER_AUTOCREATE=false
INVITE_FROM_ADDRESS="[email protected]"
LOG_FILE_PATH="%kernel.logs_dir%/%kernel.environment%.log"
MAILER_DSN="smtp://redacted"
WEBDAV_ENABLED=false
SHELL_VERBOSITY=3

May 07 '25 05:05 Ramblurr

Ok I'm relieved 😅 it's consistent !

My hunch is that PHP 8.4 breaks imap_*() functions, they now need to be prefixed by \ → \imap_*(). This is sabre/dav code, in there.

Could you try to make that change and see if it works on your side?

May 07 '25 07:05 tchapi

Could you try to make that change and see if it works on your side?

Could you please provide me with a git diff / patch that I can apply that I should test?

May 07 '25 11:05 Ramblurr

Something like that (I had to copy the code from sabre/dav as it's not in my tree) should work, I hope

From 848e7647209f0d7ce0bb92035165a6e5b7b9b726 Mon Sep 17 00:00:00 2001
Date: Wed, 7 May 2025 14:24:41 +0200
Subject: [PATCH] chore

---
 src/Services/IMAPAuth.php | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/src/Services/IMAPAuth.php b/src/Services/IMAPAuth.php
index f462e94..4c8ea78 100644
--- a/src/Services/IMAPAuth.php
+++ b/src/Services/IMAPAuth.php
@@ -51,7 +51,25 @@ final class IMAPAuth extends IMAP
      */
     protected function imapOpen($username, $password)
     {
-        $success = parent::imapOpen($username, $password);
+        try {
+            $imap = \imap_open($this->mailbox, $username, $password, OP_HALFOPEN | OP_READONLY, 1);
+            if ($imap) {
+                $success = true;
+            }
+        } catch (\ErrorException $e) {
+            error_log($e->getMessage());
+        }
+
+        $errors = \imap_errors();
+        if ($errors) {
+            foreach ($errors as $error) {
+                error_log($error);
+            }
+        }
+
+        if (isset($imap) && $imap) {
+            \imap_close($imap);
+        }
 
         // Auto-create the user if it does not already exist in the database
         if ($success && $this->autoCreate) {
@@ -73,4 +91,17 @@ final class IMAPAuth extends IMAP
 
         return $success;
     }
+
+    /**
+     * Validates a username and password by trying to authenticate against IMAP.
+     *
+     * @param string $username
+     * @param string $password
+     *
+     * @return bool
+     */
+    protected function validateUserPass($username, $password)
+    {
+        return $this->imapOpen($username, $password);
+    }
 }
-- 
2.39.5 (Apple Git-154)

May 07 '25 12:05 tchapi

Thanks, that patch applied cleanly.

However now I am getting a different error:

 Error - Call to undefined function imap_open() [{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/src/Services/IMAPAuth.php","line":105,"function":"imapOpen","class":"App\\Services\\IMAPAuth","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php","line":103,"function":"validateUserPass","class":"App\\Services\\IMAPAuth","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Plugin.php","line":179,"function":"check","class":"Sabre\\DAV\\Auth\\Backend\\AbstractBasic","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/sabre/dav/lib/DAV/Auth/Plugin.php","line":135,"function":"check","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/sabre/dav/lib/DAV/Server.php","line":456,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/src/Controller/DAVController.php","line":332,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/symfony/http-kernel/HttpKernel.php","line":178,"function":"dav","class":"App\\Controller\\DAVController","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/symfony/http-kernel/HttpKernel.php","line":76,"function":"handleRaw","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/vendor/symfony/http-kernel/Kernel.php","line":185,"function":"handle","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->"},{"file":"/nix/store/jpc6jci00m6dff1fn5kwgnqzdvzhr4ki-davis-5.0.2/public/index.php","line":33,"function":"handle","class":"Symfony\q^Cmponent\\HttpKernel\\Kernel","type":"->"}] []

Line 105 is the line with return $this->imapOpen($username, $password); inside the validateUserPass function.

May 09 '25 13:05 Ramblurr

Hmmmm 🤔 — ok so this is bigger

https://php.watch/versions/8.4/imap-unbundled

Could you try to use PHP 8.3 for the time being?

May 09 '25 14:05 tchapi

@tchapi Yes, using PHP 8.3 works. I've updated the package. Could you please leave this issue open until the 8.4 issue is resolved?

May 09 '25 15:05 Ramblurr

Could you please leave this issue open until the 8.4 issue is resolved?

Of course! I'll try to work on this soon

May 09 '25 16:05 tchapi

Hi @Ramblurr @tchapi ,

I'm not sure it's 100% the same - using IMAP auth with v5.0.2 after updating from v4.4.4. I've run into this error after updating from 5.0.2 to 5.1.2. No other components changed. PHP is still 8.3, directory and file ownership & rights identical. The .env in 5.1.2 updated including the LDAP_CERTIFICATE_CHECKING_STRATEGY="try" (without it the whole davis not start to work).

security.DEBUG: Checking for authenticator support. {"firewall_name":"main","authenticators":1} []
security.DEBUG: Checking support on authenticator. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
security.DEBUG: Authenticator does not support the request. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
php.ERROR: Warning: imap_open(): Couldn't open stream {redacted.org:993/imap/ssl} {"exception":"[object] (ErrorException(code: 0): Warning: imap_open(): Couldn't open stream {redacted.org:993/imap/ssl} at /usr/local/www/davis/vendor/sabre/dav/lib/DAV/Auth/Backend/IMAP.php:48)"} []
app.WARNING: [401]: Sabre\DAV\Exception\NotAuthenticated - No 'Authorization: Basic' header found. Login was needed [] []

After checking details around the error found this issue and the connected PR, I moved back to 5.0.2, where it still works.

Edit: it seems APP_DEBUG=0 does the trick in the .env file for the below question, thx.

Perhaps it's worth to add to either to .env of README.MD or both -> to avoid auth credential written into logs. Even more perhaps it should be the default in case of PROD environments.

Related question: how should one disable the log saves sensitive auth details? I have lines where there's "Authorization: Basic REDACTED\r\n" get followed 3 times with the base64 value written out after "Authorization: Basic". Different errors:

app.ERROR
php.INFO: Deprecated: Optional parameter

Also in these 3 times, when the Base64 value written, There are the cleartext pw after "Php-Auth-Pw:" also 3x times. So the auth data exposed in the same logic twice repeated 3 times.

Is there a way I can disable these so everywhere its redacted even if PHP "stack" written out? Or to prevent the error "stack" be written into the prod.log?

Jul 06 '25 11:07 n-connect

👋🏼 I don't understand your first part — It's not related to this issue since you're on PHP 8.3, as I understand. If you're using IMAP, LDAP_CERTIFICATE_CHECKING_STRATEGY shouldn't be needed (it's for LDAP). And AFAIK, no changes were made related to IMAP between 5.0.2 and 5.1.2 that would prevent imap_open to work 🤔 on Davis' side. It's sabre/dav code in any case (that was updated to 4.7.0), so maybe something on their side? The changelog seems pretty innocuous

For your second part, there is a specific utility to filter logs, where I may have missed this case. Do you think you could propose an improvement there?

Jul 06 '25 19:07 tchapi

Thx for the quick answer. I've re-edited my post it may be more understandable on the first part :) Anyway, it seems Sabre/dav v4.70 with php8.3 has imap login issues too, at least on my part .

I've checked the code on Sabre/dav 4.7.0 one of the changes come from the php8.4 follow- ups sabre/dav #1560. Seen no code-change around imap auth. The last 2, key lines are:

php.ERROR: Warning: imap_open(): Couldn't open stream {redacted.org:993/imap/ssl} {"exception":"[object] (ErrorException(code: 0): Warning: imap_open(): Couldn't open stream {redacted.org:993/imap/ssl} at /usr/local/www/davis/vendor/sabre/dav/lib/DAV/Auth/Backend/IMAP.php:48)"} []
app.WARNING: [401]: Sabre\DAV\Exception\NotAuthenticated - No 'Authorization: Basic' header found. Login was needed [] []

I've read the log filtering, I'll cross-check how:

"Authorization: Basic \r\n" -> when still there beside the REDACTED ones
"Php-Auth-Pw: \r\n"

should be added. Right now "APP_DEBUG=0" in the .env file stops all the stack from the logs, as a quick-fix.

Jul 07 '25 07:07 n-connect

Hi @Ramblurr @n-connect 👋🏼

I've made progress in replacing the php-imap extension with a PHP-only implementation in https://github.com/tchapi/davis/pull/198.

Could you try to test the branch by any chance? The relevant changes in the config are straightforward:

Replace the IMAP server url from {host:port/flags} to host:port:

IMAP_AUTH_URL=imap.mydomain.com:993

Add the following config (adapt to your setup):

IMAP_ENCRYPTION_METHOD=ssl
IMAP_CERTIFICATE_VALIDATION=true

Thanks a lot!

Aug 31 '25 16:08 tchapi

Hi @tchapi,

Thx for the quick work! I've span-up a jail clone, replaced the existing php83 packages with php8.4.x (plus some OS level different ones on php84 version beside the imap one). Some admin steps on copying data to new Davis dir structure, finally added the two new config lines to the existing/copied env file, and removed flags from the end of IMAP_AUTH_URL

EDIT: I've made an error, so previous results came from original Davis directory structure weren't updated in NGINX config (yet)! Redoing the tests with these additional steps I forgot:

So, the map-replacement branch's dir first gave an 500 error, that came from the missing LDAP_CERTIFICATE_CHECKING_STRATEGY="try" line necessary from v5.1.2 (I rolled back from there cause of the IMAP errors). -> success
Also it needed the DB migration in the new Davis dir: bin/console doctrine:migrations:migrate (RTFM of course) -> success
as a result http error 500 gone in web-ui, it says

Version : 5.2.0 (SabreDAV 4.7.0)
Auth : IMAP

Then, the `` IMAP_AUTH_URL=imapserver.com:port format updated by removing the "{}" brackets

So again:

Peter Parker bit by a radioactive spider, in another jail/docker/dimension
login error on time in client macOS -> readding the same PW accepted across app restarts + manual refreshes
no login error in client IOS. BUT not seeing the test event created in macOS,
new separate passwd pop-up for CalDAV calendar separately in Linux TB's calendar -> never asked for passwords separately before. After giving PW it accepts (no 2nd, 3rd, etc. pw pop-ups), BUT not seeing the test event created in macOS,

Errors from prod.log:

[2025-09-04T22:16:12.368191+00:00] security.DEBUG: Checking for authenticator support. {"firewall_name":"main","authenticators":1} []
[2025-09-04T22:16:12.368232+00:00] security.DEBUG: Checking support on authenticator. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
[2025-09-04T22:16:12.368250+00:00] security.DEBUG: Authenticator does not support the request. {"firewall_name":"main","authenticator":"App\\Security\\LoginFormAuthenticator"} []
[2025-09-04T22:16:12.382512+00:00] php.INFO: Deprecated: Creation of dynamic property App\Services\IMAPAuth::$IMAPHost is deprecated {"exception":"[object] (ErrorException(code: 0): Deprecated: Creation of dynamic property App\\Services\\IMAPAuth::$IMAPHost is deprecated at /var/www/davis_imap/src/Services/IMAPAuth.php:64)"} []
[2025-09-04T22:16:12.382575+00:00] php.INFO: Deprecated: Creation of dynamic property App\Services\IMAPAuth::$IMAPPort is deprecated {"exception":"[object] (ErrorException(code: 0): Deprecated: Creation of dynamic property App\\Services\\IMAPAuth::$IMAPPort is deprecated at /var/www/davis_imap/src/Services/IMAPAuth.php:69)"} []
[2025-09-04T22:16:12.410314+00:00] php.INFO: User Deprecated: Since symfony/var-exporter 7.3: The "Symfony\Component\VarExporter\LazyGhostTrait" trait is deprecated, use native lazy objects instead. {"exception":"[object] (ErrorException(code: 0): User Deprecated: Since symfony/var-exporter 7.3: The \"Symfony\\Component\\VarExporter\\LazyGhostTrait\" trait is deprecated, use native lazy objects instead. at /var/www/davis_imap/vendor/symfony/var-exporter/LazyGhostTrait.php:21)"} [][2025-09-04T22:16:16.602479+00:00] app.ERROR: [404]: Sabre\DAV\Exception\NotFound - Calendar object not found [{"file":"/var/www/davis_imap/vendor/sabre/dav/lib/DAV/Tree.php","line":95,"function":"getChild","class":"Sabre\\CalDAV\\Calendar","type":"->","args"

Let me know what you need, this jail will be available till everything worked out. Moving back to prod.

Sep 04 '25 21:09 n-connect

Thanks for testing out!

[2025-09-04T22:16:12.382512+00:00] php.INFO: Deprecated: Creation of dynamic property App\Services\IMAPAuth::$IMAPHost is deprecated {"exception":"[object] (ErrorException(code: 0): Deprecated: Creation of dynamic property App\\Services\\IMAPAuth::$IMAPHost is deprecated at /var/www/davis_imap/src/Services/IMAPAuth.php:64)"} []
[2025-09-04T22:16:12.382575+00:00] php.INFO: Deprecated: Creation of dynamic property App\Services\IMAPAuth::$IMAPPort is deprecated {"exception":"[object] (ErrorException(code: 0): Deprecated: Creation of dynamic property App\\Services\\IMAPAuth::$IMAPPort is deprecated at /var/www/davis_imap/src/Services/IMAPAuth.php:69)"} []

These lines are just deprecation warnings, they shouldn't bother you (I'll fix them at some point). There are no error logs from what I see.

If I understand the behavior correctly, everything works, except that you created an event in macOS that you don't see in other clients, right?

If you connect to the db, can you see it in the calendarobjects table?

Sep 05 '25 07:09 tchapi

Well, almost good :)

I could use it on one of the existing client without asking password and create and event without error (not asked for auth -> no password popup) on macOS Calendar
But on IOS the new event did not appeared, on the other hand no password pop-up so auth should be good
on TB Calendar on Linux there was password pop-up, but accepted it, on the other I could not se the test event

So, I'm not sure if everything is 100% right - > that's why rolled-back to the existing older version (v5.0.2)

Edit: I'll do a recheck, and create another event[s], and check the DB manually too. Maybe I did something else wrong too.

Sep 05 '25 07:09 n-connect

@tchapi,

TLDR; it kinda works 😊 I'd say go for it, also would be good to see @Ramblurr 's input too. No windows/android clients here..

Mem usage of jails almost tripled:

v5.0.2 with php83 is 66.1M
v5.2.0 with php84 is 161.9M -> I think it should not come from the php84 upgrade alone

Did another test run, all clients connected, the Thunderbird calendar asked for password only again. Make a kind of 3way check:

new calendar item in macOS,
appeared on IOS,
not appeared on TB

I'm not sure the reason, but I've either restarted the clients or make them manually refresh (macOS / TB has such option).

Than removed the new item on IOS:

not refreshed on macOS (eg. the deleted item still there despite the manual refresh)

Created a new item on Linux TB:

appeared on on IOS,
not appeared on macOS

So, I'm kind of puzzled 😊 IOS client in the middle sees everything/updates everything, its delete goes through (checked on db level, prod.log not updates, since last midnight ). Perhaps the desktop calendars are still catching those items created with themselves? I don't know...

Parallel question: the prod.log under davis/var/log/ is not getting updates, even I've restarted the jail , than inside the php_fpm and the NGINX service multiple times. In simple terms, the filedate of the database:

-rw-r-----   1 www www 548864 Sep  5 19:50 data.db

The same for the prod.log:

-rw-r-----  1 www www 840536 Sep  5 00:16 prod.log

What should be the solution to get the prod.log gets written continuously?

AAAND again (or still?), the application writes the cleartext version of the user's password into the logs beside the base64 version (BASIC http auth) depending on the issue. APP_DEBUG=0 is in the .env files, which I've thought the solution for this based on Symphony docs - unfortunately it's not. :) I should open a separate issue for this, right?

Sep 05 '25 18:09 n-connect

What should be the solution to get the prod.log gets written continuously?

The production log should be quiet (no lines written), except if there is an error, in which case a full trace will be written

AAAND again (or still?), the application writes the cleartext version of the user's password into the logs beside the base64 version (BASIC http auth) depending on the issue. APP_DEBUG=0 is in the .env files, which I've thought the solution for this based on Symphony docs - unfortunately it's not. :) I should open a separate issue for this, right?

You can provide a PR to https://github.com/tchapi/davis/blob/main/src/Logging/Monolog/PasswordFilterProcessor.php if you can pinpoint the related log pattern. I'll have a look, it may be due to the change in the IMAP function. Can you paste the offending log (redacting the actual value)?

Sep 05 '25 18:09 tchapi

You can provide a PR to https://github.com/tchapi/davis/blob/main/src/Logging/Monolog/PasswordFilterProcessor.php if you can pinpoint the related log pattern. I'll have a look, it may be due to the change in the IMAP function. Can you paste the offending log (redacting the actual value)?

Unfortunately I'm no good for PHP coding, and not sure AI would do any good here, but I'll check for the pattern for sure.

I've updated the previous post with men usage, I've put it here too, it worth to crosscheck from this angle too.

Mem usage of jails almost tripled:

v5.0.2 with php83 is 66.1M v5.2.0 with php84 is 161.9M -> I think it should not come from the php84 upgrade alone

Nevertheless, thx for Davis!

Sep 05 '25 19:09 n-connect

I've updated the previous post with men usage

I haven't added a lot of stuff between 5.0 and 5.2, and nothing that would inherently need more memory. Dependencies have been updated but it shouldn't yield a 3x ratio. PHP 8.4 maybe 🤷🏼 — have you enabled JIT?

Sep 05 '25 20:09 tchapi

Re the log: Can you paste the offending log (redacting the actual value)?

Sep 05 '25 20:09 tchapi

I've updated the previous post with men usage

I haven't added a lot of stuff between 5.0 and 5.2, and nothing that would inherently need more memory. Dependencies have been updated but it shouldn't yield a 3x ratio. PHP 8.4 maybe 🤷🏼 — have you enabled JIT?

Checked for differences: in the new one there are 3 chlld processes with almost 60M each instead of 14M-33M. My guess was the php84 upgrade must replaced values the previous php-fpm config, but no. Same number of childs and so on, maybe some other parts deeper/different module config.

Edit: Snippet from the php-fpm.d/www.conf, which identical on the existing and the imap-modified Davis:

pm = dynamic                                                                                                                    
pm.max_children = 3                                                                                                             
pm.start_servers = 2                                                                                                            
pm.min_spare_servers = 1                                                                                                        
pm.max_spare_servers = 2                                                                                                        
pm.max_requests = 150

Sep 05 '25 23:09 n-connect

Re the log: Can you paste the offending log (redacting the actual value)?

Yepp, will cut them out

Edit: Here are all. Because the pw dumping samples are really long ones, I've put them in a text file and attach instead of paste here as code.

The main types with pw/HTTP Basic dumps, sorted by error number increasing order:

app.ERROR: [400]: Sabre\DAV\Exception\BadRequest - The {DAV:}property-search element must contain one -> multiple ones from Dec.18., 2024, when moved to Davis from my IMAP-Auth modified Baikal, up until today.
app.ERROR: [404]: Sabre\DAV\Exception\NotFound - Calendar object not found -> I'm sure its because of my bad upgrade attempt steps / created test events during that.
app.ERROR: [412]: Sabre\DAV\Exception\PreconditionFailed - An If-Match header was specified, but none of the specified ETags matched. -> no idea, first came May 05., 2025

Analisys for the pw dumping ones' content:

Just before the first 500 and 2nd 500 error tags within the log line, the Davis' code responsible filtering out the very same sensitive auth stuff does its job multiple times: you1ll find "REDACTED" ones.
After the 2nd HTTP/1.0 500 Internal Server Error comes the problem. You'll find the passwords' dumps and the HTTP Basic encoded "user:password" in Base64 dumps multiple times.
All the baikal tags comes from NGINX reverse proxy config proxy_set_header X-Script-Name /baikal; remnants from Baikal's time. I think its not cause issue, but fixme -> I won't remove it till its identified as an error point to make sure keep the environment intact
[Auth] values replaced with samplepasswd and sampleBasic.

Because basically I've eyeballed the whole Davis log from my start, I've collected all the types of problematic outputs - even without pw dumps. My config of DEBUG=OFF in .env comes around July 6 2025 or a week before. But I got security.DEBUG messages until today -> I must do something wrong about disabling DEBUG log :)

I'm happy to make 3(?) new separate issues for the pw dumping ones and for all the others (for example the Deprecated ones and the Deprecated ones with complains about IMAP, or Symphony

.davis-prod.log

)

Sep 05 '25 23:09 n-connect

Ok, looked a bit. Just to understand correctly, are you having these logs in a production instance (APP_ENV=prod) ? You shouldn't set APP_DEBUG in any case, APP_ENV is the only thing you need (see configuration in the readme)

The logs are coming from the underlying stacks (either Sabre or Symfony), but they appear because you're in debug mode explicitly, so it's pretty normal. Davis is not redacting anything in here (REDACTED is actually done by sabre/dav here) as it's too deep down the stack.

So as far as I understand, there's nothing much to do (be sure to set your production instance to APP_ENV=prod and remove any APP_DEBUG env).

On the actual matter at hand (IMAP) - @Ramblurr by any chance, have you had time to have a look at the PR?

Sep 14 '25 16:09 tchapi

Thx fox checking!

Ok, looked a bit. Just to understand correctly, are you having these logs in a production instance (APP_ENV=prod) ? You shouldn't set APP_DEBUG in any case, APP_ENV is the only thing you need (see configuration in the readme)

I'm in prod, the log file called prod.log since I've moved there via APP_ENV=prod. I've did applied the APP_DEBUG=0 , found in Symphony docs. Anyway, it seemed to help, but later turned out it did not, hence we are talking about it.

Checked again the configuration to make sure I was not skipped anything. Up until now I have had no setup lines for birthdays, and publc calendars -> now I added them, birthday stayed the default one, public cals disaabled

The key quotes from the .env file:

APP_ENV=prod
APP_SECRET=redacted
APP_DEBUG=0
...
AUTH_METHOD=IMAP
...
IMAP_AUTH_URL=redacted
IMAP_ENCRYPTION_METHOD=ssl
IMAP_CERTIFICATE_VALIDATION=true
IMAP_AUTH_USER_AUTOCREATE=true
...
LDAP_CERTIFICATE_CHECKING_STRATEGY="try"

# Do we enable caldav and carddav ?
CALDAV_ENABLED=true
CARDDAV_ENABLED=true
WEBDAV_ENABLED=false
...
LOG_FILE_PATH="%kernel.logs_dir%/%kernel.environment%.log"

The logs are coming from the underlying stacks (either Sabre or Symfony), but they appear because you're in debug mode explicitly, so it's pretty normal. Davis is not redacting anything in here (REDACTED is actually done by sabre/dav here) as it's too deep down the stack.

Ok, I'm following you here. If you are looking my .env file's snippets, where debug is disabled first by prod mode: it is in prod since it is used in prod :D And than with that APP_DEBUG=0 what do you think can make Davis run in debug mode?

So as far as I understand, there's nothing much to do (be sure to set your production instance to APP_ENV=prod and remove any APP_DEBUG env).

As a summary:

Davis should run in prod mode, as it has been set,
The log file named prod.log confirming it is in prod mode,
The Symphony's docs hit APP_DEBUG=0 added too -> did not help,
bc I'm still getting such deep debug level messages, last one from Sep 9th, 2025.

Can you think of any other place where the PHP Debug level can be overwritten for Davis, of for all PHP app system wide? I've already checked and re-checked the main php config files under etc (BSD has them within /usr/local/), no trace for DEBUG level config at all in them:

/etc/php.conf, /etc/php-fpm.conf, /etc/php-fpm.d/www.conf

On the actual matter at hand (IMAP) - @Ramblurr by any chance, have you had time to have a look at the PR?

On the actuall matter, I have moved since the last post to this imap_mod version -> IMAP_AUTH still good on this instance, thanks!

Sep 14 '25 17:09 n-connect

The log file named prod.log confirming it is in prod mode,

Correct

The Symphony's docs hit APP_DEBUG=0 added too -> did not help,

You should remove that line altogether, it's useless

Davis does not run in debug mode as far as I can tell. Maybe sabre/dav outputs headers in any case 🤷🏼 in which case we could pattern-grep and sanitize them before they get sent to the logging descriptor, but I'd rather not go there.

You could maybe scrap the vendors folder and reinstall the dependencies with --no-dev (see here) in case it helps

Sep 14 '25 20:09 tchapi

Davis does not run in debug mode as far as I can tell. Maybe sabre/dav outputs headers in any case 🤷🏼 in which case we could pattern-grep and sanitize them before they get sent to the logging descriptor, but I'd rather not go there.

You could maybe scrap the vendors folder and reinstall the dependencies with --no-dev (see here) in case it helps

Will do. This is a point where I did not followed the install docs, I've missed the --no-dev for sure. And from the very beginning - if you do make a mistake, make it big... 🙂 Thanks!

Sep 15 '25 08:09 n-connect

I've made progress in replacing the php-imap extension with a PHP-only implementation in #198.

Sorry for the delay. I can test this this week. Some questions:

"You should also explicitely define whether you want new authenticated users to be created upon login:" I don't understand this exactly, what do you mean by have "new users authenticated created"? also there's a typo ;-)

Also could you add a few sentences explaining what we need to do to migrate an existing IMAP setup? Is it just changing the env vars?

Sep 29 '25 16:09 Ramblurr

Hey @Ramblurr ,

"You should also explicitely define whether you want new authenticated users to be created upon login:" I don't understand this exactly, what do you mean by have "new users authenticated created"? also there's a typo ;-)

This is the users' autocreate function. This is one of the reasons I've stopped patching Baikal after made the IMAP auth work in that code -> it works in Davis and for LDAP too. So, if you need that any user, who has a working IMAP (or LDAP,) account, should have a user created automatically in Davis you can set that up: IMAP_AUTH_USER_AUTOCREATE=false or LDAP_AUTH_USER_AUTOCREATE=false

Sep 29 '25 16:09 n-connect

davis davis copied to clipboard

davis does not work with with php 8.4+ because of the imap removal from core

Update

Problem

davis
davis copied to clipboard