DAVx cannot find CalDAV or CardDAV service

[oscar]

Hi all,

I upgraded to 26.5.20260507 and DAVx stopped working; login failures.
I was still using the regular login method, so in Configuration I now use “Apppassword” for CallDAV/CardDAV sync and eSync (ActiveSync).
In my account settings (“Security & Passwords” -> “Application Passwords”) I created a token for “CalDAV / CardDAV” sync and “eSync”. Using my username and this token I try to discover the service using my sites base URL, but nothing is found.
I don’t see login failures in Access Log anymore, but also no successfull logins from my device.

What am I missing?

Thanks in advance,
Oscar

[oscar]

I followed all steps in EGroupware Maintenance Release 23.1.20251021 and Access to EGroupware via WebDAV (CalDAV/CardDAV), but when I try to login using the webbrowser (via domain.tld/groupdav.php), I can’t get access.
Using my regular password with my username I see there’s a “Bad login or password” in the access log, using apppassord I created for CalDAV/CardDAV and eSync I don’t see anything in Access log.

[StefanU]

Hi Oscar.

Will downgrading help?:

Manual (container) update/downgrade in a Docker installation

Stefan

[bbegw]

Hi oskar,

the apppassword needs to have access to caldav/carddav AND the applications you like to use e.g. calendar and adressbook. Similar for infolog or if using esync, you also need mail there.

Birgit

[oscar]

Hi Birgit,

Thanks, that helps. Not that I got it working already, but in the meantime I also testen with a deliberately wrong token as apppassword; then I do get blocked (errors in Access Log) so now I’m sure with the correct token I do get proper access to groupdav even though I don´t see successfull logins in Access Log.
Granting access to several apps didn’t help yet, but for now I have enough pointers to do some debugging myself first.
I might come back with more questions if I found something, or with a “Yeah” messages.

Thankd so far,
Oscar

[oscar]

Problem is in my server. For 30 years already I’m hosting multiple domains on a server with my hosting provider. Since 20 years eGroupware is one of the servers I’m running.
I always installed the docker files at my server, with some manual work I got it running every time, until now.

I found a few more issues in the meantime. I installed docker at my local system now anbd moved the database and sqlfs there, everything works fine there.

[RalfBecker]

Problem is in my server.

What PHP version are you using on the server?

We got a report of EGroupware not installing/running on PHP 8.2 and I found a PHP 8.4 syntax in the code, which does not stop our PHP 8.5 containers, but obviously everything below PHP 8.4. Our minimum requirement is PHP 8.2.

fix PHP 8.4+ syntax as we're still only requiring 8.2

I’m just building a new maintenance release, which will fix this among other regressions in 26.6.20260616.

Ralf

[oscar]

Hi Ralf,

This server is running 8.4.
8.5 is already available; over the next few days I’ll switch to that release and do some more testing.

Oscar

[oscar]

I tested with PHP8.5 and 26.6.20260619, but no difference. I suppose I’m missing some of the requirements. I temporaly moved this domain to another server where I can use docker, so I have a workaround until I found a permanent solution.

Oscar

[zoundz]

This is probably not a good solution, but commenting out the first section of groupdav.php that begins with the comment “// check we either have a session cookie, or an Authorization header, otherwise directly return 401 Unauthorized” seems to fix the problem. It came in with 26.6.20260616 AFAICT. It probably opens up some sort of security issues. Maybe Ralf can fix this so it works. My system is running PHP 8.3 and doesn’t have anything later available in a turnkey linux/apache environment.

No flames please - it may be a bad idea but it seems to work.

[RalfBecker]

As you write here in the thread for the first time, what problem are you trying to fix?

I suggest open a new thread describing your problem, and that commenting out the mentioned coded fixed it for your.

That code was only added to stop clients without password earlier, so they don’t take to many resources and getting declined later anyway.

Ralf

[zoundz]

Ralf
I was replying to the topic of the thread. All of a sudden, after an update, my DAVx synced calendar couldn’t find the CALDAV server that had been working for quite a while. I tried all sorts of different approaches, but it kept being unable to connect to the server. I tried adding the “required” line to the groupdav.htaccess file as indicated in the groupdav.php file, but that didn’t seem to make any difference. I started comparing groupdav.php files from earlier releases and found that the block of authorization code was added in a relatively recent update. After backing up my EGW database. I tried commenting out that block of code in groupdav.php and the problem went away. I don’t know why that block of code was failing. As I indicated in my post, I have no ability to update php on the server system beyond php 8.3. The whole thing is running on an Asustor NAS, so I can’t just install a whatever php version I feel like.

While this is my first time posting on this forum, I’ve been chasing bugs and problems in code since 1964, Not, as they say, my first rodeo.

[RalfBecker]

Nothing of the code you commented out has any problem with PHP 8.3.

There where some diagnostic logging into the error-log, please post what was logged in your case, and how PHP is running for you (Apache, PHP FPM, …).

Ralf

[zoundz]

Ralf
I can’t find an error.log with any current log info. The only one I can find in the egw directory has nothing after 2019, so not being used. Is there a debug switch somewhere to turn on error logging? I un-commented the section in question and induced a failure, but there was no entry in the only “error.log” file I could find. There is an “auth.log” file in the files directory, but it seems to only show sql auths and website logins - nothing from groupdav.

As far as apache and php on my system, they are both pretty much opaque to me. The whole system is an embedded linux being run by Asustor’s NAS OS. This only provides me with very limited control over what’s going on and presents me with a gigantic maze of linux directories to paw through command line. There was nothing in “var/log/messages” that was of any interest.

Let me know if there is any other testing I can do. I will happily run groupdav.php tests if it will help.