[3.4.0.24][4.0.1.48] CalDav sync with Nextcloud server fails

Bug Reports
, ,
#21

Thank you for the test. Let say that there is no bug in the server then.

Reading again the logs you provided and looking at this interesting thread : https://help.nextcloud.com/t/davdroid-no-longer-works-with-nc/579/31
I now think that we need to do something with cookies. The first REPORT is asking to set cookies in its response headers, see :

 [D] unknown:0 - “\tSet-Cookie : oc_sessionPassphrase=gVM%2BDWMGpVRFgHk4DOY9y9Wng5T3FazMKBh2QqqQWdy3iSyzA%2BQ%2BIcqVyeAStwglfjiSaHaJIxKQmr%2B0DaEzg5VSNFM1%2B3y7%2Fwmldm9n0Kh5nNqzEL%2BrTHKGYfl7TSr%2B; path=/SUBDIRECTORY; secure; HttpOnly”
 [D] unknown:0 - “oc7z3h5oa5ry=2n9jnmdf7cl0mj4k6odi23uuk2; path=/SUBDIRECTORY; secure; HttpOnly”

Currently the sync plugin for CalDAV is not doing anything related to cookies. And then, the two next requests are failing with 503.

I’m trying to find documentation on the web about how Nextcloud is handling this kind of session security. I’ll get back when I have something.

1 Like
#22

@dyraig, may you try this package : https://share.mailbox.org/ajax/share/02b8e65d0eca2f4c2a666d3eca2f4bc58f9b7a6f5bc306ea/1/8/MzQ/MzQvMg

It has been built on top of version in 4.0.1.x, with an additional commit that stores the cookies sent by the first REPORT and try to send them back to the server on each following PUT, DELETE or REPORT. I’ve no idea if it could help or not, or even if it will actually do the cookie passing, because I cannot test it. Can you provide a full log from device from msyncd ?

1 Like
#23

Will do, thank you! I should get around to it tonight, I hope - will keep you posted!

#24

No luck, looks like something with this version is not quite ok:

Summary

[D] unknown:0 - Start sync requested for profile: “caldav-sync-60”
[D] unknown:0 - Removing queued profile change sync due to sync trigger: “caldav-sync-60”
[D] unknown:0 - Synchronizer::getBackUpRestoreState
[D] unknown:0 - Starting sync with profile “caldav-sync-60”
[D] unknown:0 - Disable sync on change: false false
[D] unknown:0 - Starting oop plugin “caldav-sync-60”
[D] unknown:0 - Starting process “/usr/lib/buteo-plugins-qt5//oopp/caldav-client” with plugin name “caldav” and profile name “caldav-sync-60”
/usr/lib/buteo-plugins-qt5//oopp/caldav-client: symbol lookup error: /usr/lib/buteo-plugins-qt5//oopp/caldav-client: undefined symbol: _ZN5Buteo11SyncResults16staticMetaObjectE
[D] unknown:0 - Process “/usr/lib/buteo-plugins-qt5//oopp/caldav-client” started with pid 3997
[D] unknown:0 - Process “/usr/lib/buteo-plugins-qt5//oopp/caldav-client” with pid 3997 was unable to register DBus service: “com.buteo.msyncd.plugin.profile-caldav-sync-60” | “com.buteo.msyncd.plugin.caldav-sync-60”
[D] unknown:0 - Client plug-in runner initialized
[D] unknown:0 - New network state: true New type: “WLAN” ( 2 )
[D] unknown:0 - Network status:
[D] unknown:0 - Online:: true
[D] unknown:0 - Connection:: 2
[D] unknown:0 - sync-ui dbus interface is getting called
[D] unknown:0 - Sync session started
[D] unknown:0 - ClientPluginRunner started thread for plugin: “caldav-sync-60” , returning: true
[D] unknown:0 - attempt to start sync session due to network session opened succeeded.
[D] unknown:0 - Sync status changed for account “60”
[W] unknown:0 - Invalid reply for init from plugin
[W] unknown:0 - Could not initialize client plugin: “caldav”
[D] unknown:0 - Sync running for 60
[D] unknown:0 - Process “/usr/lib/buteo-plugins-qt5//oopp/caldav-client” finished with exit code 127
[W] unknown:0 - Invalid reply for getSyncResults from plugin
[D] unknown:0 - Session finished: “caldav-sync-60” , status: 3
[D] unknown:0 - Clean up session for profile “caldav-sync-60”
[D] unknown:0 - Stopping the OOP process for “caldav”
[D] unknown:0 - Sync status changed for account “60”

Especially this line:
/usr/lib/buteo-plugins-qt5//oopp/caldav-client: symbol lookup error: /usr/lib/buteo-plugins-qt5//oopp/caldav-client: undefined symbol: _ZN5Buteo11SyncResults16staticMetaObjectE

#25

Oups, my bad of course. I compiled with a modified version of Buteo framework on my SDK (the current master, which has new symbols I added compared to the one present in 4.0.1.x). I need to recompile a package with the proper Buteo version. Here is a version with the right (hopefully) dependencies : https://share.mailbox.org/ajax/share/0fa051ea0ff7cc4dfbed164ff7cc4488a5fbc508b2a6e313/1/8/MzQ/MzQvNA

#26

For anyone following along at home, investigation continues. dcaliste mentioned to me “The two possibilities are either server side or a bug with Qt. It is manifesting as a race condition on server with some data from a previous request payload that are not trashed when the request is handled and are interpreted as header for a new request.”

1 Like
#27

My apologies, I should have updated a long time ago… Yes, after a lot of experimenting, there is some evidence that the underlying problem may lie with OpenBSD httpd. I don’t have as much time as I like to run further tests, but the next step will be to try nginx on OpenBSD instead and see whether the situation changes then. I will report back in due course.

#28

I have the same issue with SFOS 4.1.0.24 and nextcloud 19 (and then 20) running on linux. So I don’t think this is limited to OpenBSD, but rather the generic httpd stack used by everybody. And in fact, evolution, thunderbird etc are all happy. But the SFOS Calendar isn’t.
BTW, whether using the nextcloud account or the CalDav account does not make a difference for me. But I noticed that the nextcloud account creation is showing “setting up account” forever. Until one closes the settings app and reopens it. Then all is fine.
The nextcloud and caldav accounts find all calendars correctly, but there is no sync possible.

#29

I started to have a regression on this with the update to Verla

#30

Actually I removed one totally messed up invite from MS Teams and it syncs again. But this wasn’t really visible from the log file. Could we unclutter the log file a bit? :pensive:

#31

If you can send me (or dcaliste) a .ics which includes the “messed up invite” we can add a workaround for similar cases so that it doesn’t block synchronisation - that would be very helpful!

#32

Unfortunately, time flies and I think this ics file is gone for good. For the moment, all sync with my nextcloud works fine. Next time I encounter, I will keep it and send it to you.

#33

Finally some more data… Next to the OpenBSD-based Nextcloud, I now also have a NextcloudPI (Raspberry Pi 2 with Raspbian Buster and NextcloudPI installed). With that server, the Xperia can connect. Still bugs me, though, what it is that SailfishOS is triggering on the OpenBSD/httpd/Nextcloud installation that none of the other clients triggers… I’ll dig further once I have some time on my hands - no idea when.

1 Like