Davdroid no longer works with NC

Okay. The patch is not making a difference with Davdroid for me. Caldav syncing is working with Gnome desktop for me, so that’s something.

I also can sync my contacts with Evolution.

EDIT: I can sync my calendars using DAVdroid 0.9.1.3

What is that stupid limit of 3 comments for new users? I need to edit my comments…

I also updated from ownCloud 9 and everytime when I try to connect my nextCloud with a browser (Firefox or Chrome), I get the 503 error.

I checked my cookies and found out that the website-login to my nextCloud works after deleting the following cookies:

nc_sameSiteCookielax
nc_sameSiteCookiestrict

Maybe this could also be the problem with Davdroid?

Adding some more debug information here, I purchased CalDAV-Sync for the express purpose of seeing if it worked with Nextcloud. It does so I am betting this is an issue with DavDroid.

1 Like

All tests worked fine on all machines I tested, I do need a complete traffic dump to debug this issue. But I do bet it’s DAVDroid related.

Can anybody with this issue sniff their unencrypted traffic and get me a copy so I can debug this? THX a lot.

I do have the same problem. I upgraded from ownCloud 8.2.5 to nextCloud 9 today and all my calendars and contacts stopped syncing.

I can provide a log using mod_dumpio tomorrow, that should contain all relevant data, right?

Edit: I just tested “Easy DAV for ownCloud” and it works fine. It’s based on an older version of DAVDroid!

You can find a mod_dumpio trace here: http://pastebin.com/K48Beqhn

I replaced Cookie, Authorization, IP address and a few other values with ‘x’ to protect my server. Unfortunately, it doesn’t go down to a real packet capture as I’m on a SSL-only host.

DAVdroid verbose logs should contain all HTTP headers, too, so I guess those would be enough to trace the problem?

Ok. From http://pastebin.com/K48Beqhn it seems the following:

  1. DAVdroid sends a request with only the Nextcloud session cookie.
  2. The server sends back a 503 AND the new expected cookies which is HTTP standard compliant behaviour.

DAVdroid should in this case get the new cookies and send them back in the next request. That’s what the HTTP specs say :see_no_evil:

That it works for some people is probably caused by the fact that they don’t have an old session open or so. Just my guess…

That would probably say and help more than the mod_dumpio dump :slight_smile:

here we go (it’s from a different request, though): http://pastebin.com/72G03Whn

Well, you asked for a complete traffic dump and not the logs, so I provided Apache’s dump :slight_smile:

Edit: Isn’t there already a debug log included in the first post?

DAVdroid did indeed send not all cookies for every request. This has been fixed in version 1.1.1 and our tests show that it now works with Nextcloud.

I still wonder why Nextcloud returns 503 errors just because some cookies were not sent, but this should be discussed somewhere else.

2 Likes

Thank you! :heart: :dancer: :rocket:

As a security hardening we require two special cookies to be existent on any request. Those cookies have a special flag that instruct browsers to not include it cross-domain, thus making CSRF even a non-issue if somebody would be able to find an endpoint with missing token. (only supported in Chrome yet though)

The implementation in Nextcloud is pretty naîve and assumes: If somebody sends a cookie they will send all required ones. If these are not send it issues a 503 and sends the required cookies so on the next request the client will include these cookies as well.

(I have just omitted various RFC references because “Sorry, new users can only put 2 links in a post.”)

Yes, that was to be the problem. DAVdroid did not send all cookies, but only some of them.

However, where do specs say that a 503 response is “standard-compliant behavior”? RFC 7231 6.6.4 says:

So, 503 doesn’t seem appropriate. If the behavior of enforcing cookies for stateless WebDAV is really intended (which I find strange), 403 + a textual explanation would be appropriate in my opinion:

Also, the whole cookie-forcing behavior seems quite strange to me:

  1. It seems to be consensus that CalDAV/CardDAV is not stateful (except when defined so, like for locking operations) and clients don’t have to support cookies.
  2. So we only have to look at the case where cookies are basically supported. In this case, Nextcloud insists on all cookies to be sent and refuses requests with 503 if not all cookies are sent. However, RFC 6265 makes quite clear that it’s up to the User-Agent which cookes are stored and which are not. For instance, you might think of a user/browser plugin which blocks certain cookies by name (but not all cookies).

So, in my opinion:

  • Cookie support should not be required by Nextcloud CalDAV/CardDAV.
  • It can’t be expected that a client accepts and serves all cookies, so cookies should only be used for optional tasks (like Horde uses a session cookie for grouping requests to one “sync session”).
  • If Nextcloud does expect clients to accept and serve all cookies, requests should not be refused with 503, but with 403 plus an textual explanation what went wrong.

I will say that I also found the 503 status quite confusing. I was tweaking the concurrency limit settings in Apache and php-fpm trying to see if that would resolve it.

When will the davdroid update make it to the Play Store?

I just updated to 1.1.1. from F-Droid (it’s already available there!) and, so far, it syncs properly without any errors! Thanks for fixing this!

EDIT: Please remove this stupid “3 posts per topic” limit for new users! IMHO, it prevents users from helping resolving issues.

Upgraded from OwnCloud 9.0.2 to Nextcloud 9.0.51 one hour ago. Everything without any problems :sunny:

  • Sync with DAVdroid 1.1 (FDroid) works without any problems
  • Sync with MAC OS X 10.11.5 Card- and CalDav no problems
  • Sync with Thunderbird 45.1.0 and 45.1.1 on MAC OS X 10.11.5 together with Inverse SOGo Connector 31.0.2 no Problems

Thanks a lot for the easiest OwnNextCloud upgrade ever :slight_smile:

1 Like

At the moment, Google doesn’t allow us to update DAVdroid in Play Store. We have now created a gplay flavor without donation link, for which I hope that it resolves the problem.

2 Likes

The update for Davdroid just hit my device and it has solved the issue. Thank you so much for your support!!!

1 Like

@davdroid Yeah Google started prohibiting donation links a while ago. Only thing that comes to my mind would then be to implement their billing API so Donations could be done through via in-app purchases, even though that would mean Google getting a 30% share on any purchase…which makes it clear why they changed their policy…