Logs from iRony/error.log

[25-Dec-2022 12:19:55 -0500]: PHP Error: syntax error, unexpected 'CardDAV' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) (error 500)
#0 /usr/share/roundcubemail/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile('/usr/share/iRon...')
#1 [internal function]: Composer\Autoload\ClassLoader->loadClass('Kolab\\CardDAV\\L...')
#2 /usr/share/iRony/lib/Kolab/CardDAV/UserAddressBooks.php(74): spl_autoload_call('Kolab\\CardDAV\\L...')
#3 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Collection.php(57): Kolab\CardDAV\UserAddressBooks->getChild('26f518c2597b3e7...')
#4 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Tree.php(111): Sabre\DAV\Collection->childExists('26f518c2597b3e7...')
#5 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAVACL/Plugin.php(834): Sabre\DAV\Tree->nodeExists('addressbooks/er...')
#6 /usr/share/roundcubemail/vendor/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\DAVACL\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#7 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(456): Sabre\DAV\Server->emit('beforeMethod:PR...', Array)
#8 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(253): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#9 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(321): Sabre\DAV\Server->start()
#10 /usr/share/iRony/public_html/index.php(194): Sabre\DAV\Server->exec()
#11 {main} in /usr/share/iRony/lib/Kolab/CardDAV/LDAPDirectory.php on line 51 (PROPFIND /iRony/addressbooks/user@domain.tld/26f518c2597b3e75/)

i've worked around this arror by removing the string "CardDAV\Xml\Request\AddressBookQueryReport" in line 51 introduces by https://git.kolab.org/rI59977da735b6892075fffc802e4b656d94d75cd2

Thanks, this is working for me as well.

This is strange - /usr/share/roundcubemail/vendor shouldn't be empty. Did the recent upgrade of the roundcubemail package fail? Is it in a half-installed state?

it is not empty, the created link (/usr/share/iRony/vendor/) points to ../roundcubemail/vendor, witch seems to cause a problem.

If the /usr/share/iRony/vendor points to /usr/share/roundcubemail/vendor everything works fine.

rm /usr/share/iRony/vendor
ln -s /usr/share/roundcubemail /usr/share/iRony/vendor

Hmm, so replacing the relative symlink with an absolute symlink fixes the problem for you? Interesting.

In T7097#97769, @sicherha wrote:

Hmm, so replacing the relative symlink with an absolute symlink fixes the problem for you? Interesting.

Correct

I think originally mu roundcoube update failed to finish or wasn't in place when iRony was updated. However, the update is in place now so the link was not empty any longer. I will try removing the work around from earlier and creating an absolute symlink to test.

I removed the fix from earlier and created an absolute symlink and it still failed with this in the iRony error logs:

[28-Dec-2022 11:54:53 -0500]: PHP Error: syntax error, unexpected 'CardDAV' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) (error 500)
#0 /usr/share/roundcubemail/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile('/usr/share/iRon...')
#1 [internal function]: Composer\Autoload\ClassLoader->loadClass('Kolab\\CardDAV\\L...')
#2 /usr/share/iRony/lib/Kolab/CardDAV/UserAddressBooks.php(74): spl_autoload_call('Kolab\\CardDAV\\L...')
#3 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Collection.php(57): Kolab\CardDAV\UserAddressBooks->getChild('157b7b01597b3e7...')
#4 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Tree.php(111): Sabre\DAV\Collection->childExists('157b7b01597b3e7...')
#5 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAVACL/Plugin.php(834): Sabre\DAV\Tree->nodeExists('addressbooks/er...')
#6 /usr/share/roundcubemail/vendor/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\DAVACL\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#7 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(456): Sabre\DAV\Server->emit('beforeMethod:PR...', Array)
#8 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(253): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#9 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(321): Sabre\DAV\Server->start()
#10 /usr/share/iRony/public_html/index.php(194): Sabre\DAV\Server->exec()
#11 {main} in /usr/share/iRony/lib/Kolab/CardDAV/LDAPDirectory.php on line 52 (PROPFIND /iRony/addressbooks/user@domain.tld/157b7b01597b3e76/)

This is the change at line 51 of LDAPDirectory.php that is working:

protected $query;
//protected CardDAV\Xml\Request\AddressBookQueryReport $query;

Looks like commit https://git.kolab.org/rI59977da735b6892075fffc802e4b656d94d75cd2 is to blame.

Could you try out the following?

1. Change the offending line to protected Sabre\CardDAV\Xml\Request\AddressBookQueryReport $query;
2. If it works, switch back to a relative symlink

It did not work:

[28-Dec-2022 12:30:51 -0500]: PHP Error: syntax error, unexpected 'Sabre' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) (error 500)
#0 /usr/share/roundcubemail/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile('/usr/share/iRon...')
#1 [internal function]: Composer\Autoload\ClassLoader->loadClass('Kolab\\CardDAV\\L...')
#2 /usr/share/iRony/lib/Kolab/CardDAV/UserAddressBooks.php(74): spl_autoload_call('Kolab\\CardDAV\\L...')
#3 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Collection.php(57): Kolab\CardDAV\UserAddressBooks->getChild('157b7b01597b3e7...')
#4 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Tree.php(111): Sabre\DAV\Collection->childExists('157b7b01597b3e7...')
#5 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAVACL/Plugin.php(834): Sabre\DAV\Tree->nodeExists('addressbooks/er...')
#6 /usr/share/roundcubemail/vendor/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\DAVACL\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#7 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(456): Sabre\DAV\Server->emit('beforeMethod:PR...', Array)
#8 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(253): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#9 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(321): Sabre\DAV\Server->start()
#10 /usr/share/iRony/public_html/index.php(194): Sabre\DAV\Server->exec()
#11 {main} in /usr/share/iRony/lib/Kolab/CardDAV/LDAPDirectory.php on line 52 (PROPFIND /iRony/addressbooks/user@domain.tld/157b7b01597b3e76/)

Okay, next try (note the leading backslash):

protected \Sabre\CardDAV\Xml\Request\AddressBookQueryReport $query;

If that doesn't work either, let's just go back to omitting the type name.

(Sorry about the trial-and-error fest, but I'm not familiar with PHP at all.)

That did not work either:

[28-Dec-2022 14:11:32 -0500]: PHP Error: syntax error, unexpected '\' (T_NS_SEPARATOR), expecting function (T_FUNCTION) or const (T_CONST) (error 500)
#0 /usr/share/roundcubemail/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile('/usr/share/iRon...')
#1 [internal function]: Composer\Autoload\ClassLoader->loadClass('Kolab\\CardDAV\\L...')
#2 /usr/share/iRony/lib/Kolab/CardDAV/UserAddressBooks.php(74): spl_autoload_call('Kolab\\CardDAV\\L...')
#3 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Collection.php(57): Kolab\CardDAV\UserAddressBooks->getChild('26f518c2597b3e7...')
#4 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Tree.php(111): Sabre\DAV\Collection->childExists('26f518c2597b3e7...')
#5 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAVACL/Plugin.php(834): Sabre\DAV\Tree->nodeExists('addressbooks/er...')
#6 /usr/share/roundcubemail/vendor/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\DAVACL\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#7 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(456): Sabre\DAV\Server->emit('beforeMethod:PR...', Array)
#8 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(253): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#9 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(321): Sabre\DAV\Server->start()
#10 /usr/share/iRony/public_html/index.php(194): Sabre\DAV\Server->exec()
#11 {main} in /usr/share/iRony/lib/Kolab/CardDAV/LDAPDirectory.php on line 52 (PROPFIND /iRony/addressbooks/user@domain.tld/26f518c2597b3e75/)

And no woriries, I am not familiar either. Thanks for looking into this so promptly.

I believe I've found the underlying issue: typed properties (i.e. class member variables) were not introduced until PHP 7.4.0.
Source: https://www.php.net/manual/en/language.oop5.properties.php

So removing the type declaration is the way to go. I have updated D3968 accordingly.

After downgrading the kolabformat-packages as recommended here the following error comes up:

PHP Error: Starting sabre/vobject 4.0 the children property is now protected. You should use the children() method instead (error 500)
#0 /usr/share/iRony/lib/Kolab/CardDAV/ContactsBackend.php(886): Sabre\VObject\Component->__get('children')
#1 /usr/share/iRony/lib/Kolab/CardDAV/ContactsBackend.php(654): Kolab\CardDAV\ContactsBackend->_to_array(Object(Sabre\VObject\Component\VCard))
#2 /usr/share/iRony/lib/Kolab/CardDAV/ContactsBackend.php(478): Kolab\CardDAV\ContactsBackend->parse_vcard('BEGIN:VCARD\r\nVE...', '7f5dee0e-a9ab-4...')
#3 /usr/share/roundcubemail/vendor/sabre/dav/lib/CardDAV/Card.php(94): Kolab\CardDAV\ContactsBackend->updateCard('0bb000a55db4288...', '7f5dee0e-a9ab-4...', 'BEGIN:VCARD\r\nVE...')
#4 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(1137): Sabre\CardDAV\Card->put('BEGIN:VCARD\r\nVE...')
#5 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/CorePlugin.php(492): Sabre\DAV\Server->updateFile('addressbooks/ma...', 'BEGIN:VCARD\r\nVE...', NULL)
#6 /usr/share/roundcubemail/vendor/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Kolab\Utils\HTTPResponse))
#7 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(472): Sabre\DAV\Server->emit('method:PUT', Array)
#8 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(253): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Kolab\Utils\HTTPResponse))
#9 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(321): Sabre\DAV\Server->start()
#10 /usr/share/iRony/public_html/index.php(194): Sabre\DAV\Server->exec()
#11 {main} in /usr/share/roundcubemail/vendor/sabre/vobject/lib/Component.php on line 440

Wait, that means the roundcubemail package is bundling the wrong version of sabre/vobject. It should contain 3.5.3 but actually contains 4.x. What a mess...

The offending change was made here in the file buildroundcubemailtarball.sh: https://obs.kolabsys.com/package/rdiff/Kolab:16/roundcubemail-selfcontained?rev=13

@mollekopf, @machniak: Could one of you please adjust buildroundcubemailtarball.sh, recreate the tarball and bump the packages? I cannot do it myself because I don't have access to ssh://git@git.kolab.org/source/roundcubemail-skin-elastic.git.

Here is the suggested diff:

-        "sabre/vobject" : "~4.5.1",
-        "sabre/dav" : "~4.0",
-        "sabre/http" : "~5.0",
+        "sabre/vobject" : "^3.3.4",
+        "sabre/dav" : "~3.0.9",
+        "sabre/http" : "~4.0",

I have taken these version numbers from https://github.com/sabre-io/dav/blob/3.0.9/composer.json. The crux is that iRony is currently not compatible with sabre/vobject >= 4.0 - see above for the resulting error message and stack trace. sabre/dav 3.0.9 is the highest version that depends on sabre/vobject < 4.0.

I have now included the vobject compatibility fix and I'm not planning on downgrading the sabre dependencies again.
The updated iRony package is currently in Kolab:16:Testing, but I'm still fighting an obs issue that seems to somehow pull in the libkolabxml 1.3.0 update into Debian_10...

Thanks! Upgrading the code base is of course better than downgrading the dependencies. I was just unsure whether there are additional incompatibilities besides the children property being deprecated.

The current build log is looking good with respect to the libkolabxml version:

[   68s] [270/287] installing libkolabxml1v5-1.2.1-0~kolab3

It's possible that we face additional incompatibilities, we have unfortunately rather poor test-coverage on these components.
But we do need the update to get to php8 support eventually.

I pushed the iRony update to Kolab:16 now.

@raptor2101, does updating to irony_0.4.6-7~kolab1 fix the issue for you?

In T7097#98096, @sicherha wrote:

@raptor2101, does updating to irony_0.4.6-7~kolab1 fix the issue for you?

Doesn’t expect you to work this late. Yes the upgrade solves the problem for me. A happy family for new year :)

Have a nice New Year’s Eve

Do you have any helpful log entries, for example in /var/log/iRony/errors.log?

@sicherha
This error I get when using irony_0.4.6-1~kolab1, but discovery and adding calendars from Thunderbird works.

[03-Jan-2023 12:16:19 Europe/Berlin] PHP Fatal error: Uncaught Error: Call to undefined method Sabre\DAV\SimpleCollection::getETag() in /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php:1307
Stack trace:
#0 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(464): Sabre\DAV\Server->checkPreconditions(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#1 /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php(254): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
#2 /usr/share/iRony/public_html/index.php(194): Sabre\DAV\Server->exec()
#3 {main}
thrown in /usr/share/roundcubemail/vendor/sabre/dav/lib/DAV/Server.php on line 1307

@sicherha
After installing 0.4.6-7~kolab1 every time /usr/share/iRony/vendor/autoload.php vanishes and I need to "apt-get install --reinstall roundcubemail" to make the calendar 100% work in roundcubemail.
When autload.php is missing I can create appointments in roundcubemail but cannot change them... the time for example.

But then I cannot discover and chosse any calendars in Thunderbird. This does not log any errors in /var/log/iRony/errors.log.

Which version of the roundcubemail package is installed on your system? I have 1:1.5.3-0~kolab2 and the line numbers from your log don't match the code I see on my system.

I was able to reproduce the issue with autoload.php disappearing; it seems to be a problem in the upgrade paths of the packages involved but I haven't been able to pinpoint it yet.

... and I can reproduce the calendar-discovery issue: no calendars are discoverable via CalDAV any more; trying to access an existing URL gives me HTTP 404. I shouldn't have upgraded yet. 🙄

This is from the system where iRony does not work with Thunderbird (I have 2 systems).

ii irony 0.4.6-7~kolab1 all Kolab Groupware DAV Access
ii roundcubemail 1:1.5.3-0~kolab2 all skinnable AJAX based webmail solution for IMAP servers

I have found a workaround for my problem: log in with the full email address (e.g. firstname.lastname@example.org). It seems that logging in with the username only (e.g. firstname.lastname) is currently broken, but I haven't yet found out why.

Yes, calendar discovery works with full email address as login, but after choosing the desired calendars and pressing OK the chosen calendars are not activated.
Pressing the activate Button does not work.

Again, no errors in any logs.

In T7097#98177, @sicherha wrote:

Which version of the roundcubemail package is installed on your system? I have 1:1.5.3-0~kolab2 and the line numbers from your log don't match the code I see on my system.

I was able to reproduce the issue with autoload.php disappearing; it seems to be a problem in the upgrade paths of the packages involved but I haven't been able to pinpoint it yet.

Indeed you where right. It was a "different" roundcubemail package, but with the same version number... 1.5.3-0~kolab2.
In the last months I realized, that sometimes Kolab releases an update to a package without raising the version number... not good.

On my production system I have installed...
ii irony 0.4.6-1~kolab1 all Kolab Groupware DAV Access
ii roundcubemail 1:1.5.3-0~kolab2 all skinnable AJAX based webmail solution for IMAP servers
"dpkg -L roundcubemail | wc -l" shows 14891 files

On my testing system I have installed...
ii irony 0.4.6-7~kolab1 all Kolab Groupware DAV Access
ii roundcubemail 1:1.5.3-0~kolab2 all skinnable AJAX based webmail solution for IMAP servers
"dpkg -L roundcubemail | wc -l" shows 14847 files

This is really not good and will break things. Please always raise the version number.

It looks like the workaround (logging into iRony with the full email address) works fine with DAVx5 (on Android) but doesn't work with Kontact or Thunderbird.

Sigh... I was originally hoping to use my holiday to get Debian 11 support up & running, but there are too many fires to put out right now.

This is really not good and will break things. Please always raise the version number.

Indeed. Rule #1 for packagers: whenever the contents of a package change, bump its release number.
In my day job we use aptly, which refuses to accept an identically named .deb file with different contents, but I'm not aware that OBS supports that kind of check.

In T7097#98246, @sicherha wrote:

It looks like the workaround (logging into iRony with the full email address) works fine with DAVx5 (on Android) but doesn't work with Kontact or Thunderbird.

Sigh... I was originally hoping to use my holiday to get Debian 11 support up & running, but there are too many fires to put out right now.

This is really not good and will break things. Please always raise the version number.

Indeed. Rule #1 for packagers: whenever the contents of a package change, bump its release number.
In my day job we use aptly, which refuses to accept an identically named .deb file with different contents, but I'm not aware that OBS supports that kind of check.

I think in principle it would be possible to extend the obs with custom checks. On Kolab:16 I try to never push an update without updating the debian version numbers as well, but maybe I forgot in an update.
In Kolab:16:Testing I do occasionally take the shortcut of not updating it because I'm testing the rpm side of things where the obs automatically bumps the release version.
I vaguely recall that there is such a thing for the debian side as well, but it's opt in and we'd have to test how well it works.

But back on topic; there seems to be a defect in current Kolab:16 that shortlogins stopped working as expected, correct?

(Sorry about my tone in yesterday's last-night comment; I was a tad frustrated. I'd like to do what I can to help fix this as quickly as possible.)

To me it looks like we're having two issues that may or may not be connected:

1. Users are still able to log in using shortlogins, but then iRony no longer lists any calendars.
2. When logging in with the full email address, the calendars themselves are listed, but certain clients no longer see any calendar entries while others do.

In T7097#98258, @sicherha wrote:

(Sorry about my tone in yesterday's last-night comment; I was a tad frustrated. I'd like to do what I can to help fix this as quickly as possible.)

No worries, I understand it's frustrating. I'm trying to improve the situation by having better test-coverage for future changes.

To me it looks like we're having two issues that may or may not be connected:

1. Users are still able to log in using shortlogins, but then iRony no longer lists any calendars.
2. When logging in with the full email address, the calendars themselves are listed, but certain clients no longer see any calendar entries while others do.

Ok, I'll see if I can reproduce. Thanks for the clarification.

I'm trying to reproduce the thunderbird issue:

When enabling console logging I see an exception in the iRony console.log when I try to "Enable" a calendar in thunderbird (discovery works):

[13-Jan-2023 14:08:36,475413 +0100]: Kolab\CalDAV\CalendarBackend::getCalendarsForUser;
principals/john@kolab.org
[13-Jan-2023 14:08:36,475644 +0100]: Sabre\DAV\Exception\NotFound (EXCEPTION);
Node with name 'c94af441-0152-4f05-ad21-1f7bf037d179' could not be found

If I'm not mistaken this is caused by an unauthenticated PROPFIND request, which can't work it seems to me (we need the credentials to access the data).
But you're saying that with a downgraded iRony this works with thunderbird, right? Because then what I'm seeing can't be correct.

According to tcpdump -s 0 -A 'tcp dst port 80' I'm indeed getting unauthenticated PROPFIND requests, but that can't work IMO, so I'm not sure what's going on.
If anybody could confirm that they also see unauthenticated requests, and confirm what they are seeing with the old iRony, that could help.

@mollekopf

My production system with "irony 0.4.6-1~kolab1 " and "roundcubemail 1:1.5.3-0~kolab2" (older one, not the newest) shows this when I force a calendar synchronisaton in Thunderbird.

...
Host: XXXproduktionXXX
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Accept: text/xml
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: utf-8,*;q=0.1
Content-Type: text/xml; charset=utf-8
Content-Length: 144
Depth: 1
Origin: http://XXXproductionXXX
Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
...

My test system with "irony 0.4.6-7~kolab1" and "roundcubemail 1:1.5.3-0~kolab2" (the newest version) shows this when I try to activate a calendar in Thunderbird

...
Host: XXXtestXXX
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Accept: text/xml
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: utf-8,*;q=0.1
Content-Type: text/xml; charset=utf-8
Content-Length: 337
Depth: 0
Origin: http://XXXtestXXX
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
...

"Authorization" is missing on the broken test system.

Thanks for the info.

I believe this addresses the issue I've been running into: https://git.kolab.org/D3980
Thunderbird always first attempts an unauthenticated access, and relies on the WWW-Authenticate header to be returned.
This however broke due to a change in sabre-dav, resulting in thunderbird never sending the auth header.

Yes, your patch at https://git.kolab.org/D3980 works with latest irony and roundcubemail in Thunderbird again.

Now If you could find out why "shortlogins" do not work anymore would be great... otherwise I would need to login into hundreds of user profiles and change cardDAV and calDAV logins to full email address.

Thanks a lot.

Thanks for investigating this! I can confirm that D3980 solves the synchronisation issue with Kontact for me, but like @johndoe I still have to log in with my full email address. With a shortlogin, iRony does not find the associated principal.

I haven't really looked into the shortlogin issue yet, but at least for individual requests authenticated requests worked for me.
AFAIR the feature uses the username_domain roundcube config option to complete the login name if there is no domain part.

I think the username canonification is done by kolab_auth plugin. So, maybe some problem with loading plugins/configuration.

The iRony patch is now available in https://obs.kolabsys.com/package/show/Kolab:16:Testing/iRony

In T7097#99230, @machniak wrote:

I think the username canonification is done by kolab_auth plugin. So, maybe some problem with loading plugins/configuration.

The canonification code seems to be in:

• iRony/lib/Kolab/DAV/Auth/HTTPBasic.php
• roundcubemail/program/include/rcmail.php
• roundcubemail-plugins-kolab/plugins/ldap_authentication/ldap_authentication.php
• roundcubemail-plugins-kolab/plugins/libkolab/lib/kolab_ldap.php

I think the iRony/lib/Kolab/DAV/Auth/HTTPBasic.php one is what's relevant for us, but I don't see how that would have changed or where the issue could be.
@sicherha: If you want to debug this you could just add a couple of \rcube::console("string"); debug statements after having enabled console logging to see what's going on (in the _login function where this canonification happens)

@sicherha
Any news on this - shortlogin not working with latest iRony? No stress if you are busy with other things... let me know.

I have pushed iRony 0.4.7 to Kolab:16. Don't know about the shortlogins, the code seems to still work in my tests, but I don't have an actual system that supports shortlogins that I could test against thunderbird.

Thank you @mollekopf
Shortlogins still don't work, so I will wait what @sicherha can tell if he finds time looking into this.

No news yet from my side, sorry. Working life has grabbed me again, and I'll need a couple of contiguous undisturbed hours to narrow down the problem.

For now, anyone affected can work around this issue by logging in with their full email address.

The issue with shortlogins seems to stem from the transition to sabre/dav > 2.1. The AbstractBasic authentication backend API has changed since then and AbstractBasic now always uses the concatenation of the principalPrefix and the HTTP username as principal name (see https://github.com/sabre-io/dav/blob/4.4.0/lib/DAV/Auth/Backend/AbstractBasic.php#L107). To overcome this, we would need to override the check() method in iRony/lib/Kolab/DAV/Auth/HTTPBasic.php to return the canonicalized principal name:

public function check(Sabre\HTTP\RequestInterface $request, Sabre\HTTP\ResponseInterface $response)
{
    $result = parent::check($request, $response);

    if ($result[0]) {
        $result[1] = $this->principalPrefix . $this->getCurrentUser();
    }

    return $result;
}

Btw. here is a version with the fix applied: https://github.com/michaelroland/kolab-iRony/tree/fix-canonical-principal-name-from-auth (not sure if I could have somehow created a merge request on this platform here)

@mroland

Is https://github.com/michaelroland/kolab-iRony/commit/5a9cc8f0f131470caafa4253f1e7df19f57b9546 the only patch that is needed to fix the issue?

@johndoe Yes, that's the only patch needed to make shortlogins work again.

@mroland

Your patch does not work, at least for me.
My system is Debian 10 Buster (up2date).

[04-May-2023 10:46:54 Europe/Berlin] PHP Fatal error: Declaration of Kolab\DAV\Auth\HTTPBasic::check(Kolab\DAV\Auth\Sabre\HTTP\RequestInterface $request, Kolab\DAV\Auth\Sabre\HTTP\ResponseInterface $response) must be compatible with Sabre\DAV\Auth\Backend\AbstractBasic::check(Sabre\HTTP\RequestInterface $request, Sabre\HTTP\ResponseInterface $response) in /usr/share/iRony/lib/Kolab/DAV/Auth/HTTPBasic.php on line 37

Indeed, I failed to commit the latest version after I had experimented with getting rid of the use statements. So its those two commits here: https://github.com/michaelroland/kolab-iRony/compare/master...fix-canonical-principal-name-from-auth that make the patch.

Yes, now it works (tested with irony 0.4.8-1~kolab1).
Please push upstream.

I have included the patch and it's now building here: https://obs.kolabsys.com/package/show/Kolab:16:Testing/iRony

sadly, the iRony Debian 10 package ist still not published:(

I just double-checked: the fix is published, but apparently the package version didn't get bumped.

To get the fix right now, run sudo apt install --reinstall irony.