Lightning calendar sync

[jonasongithub]

I am running baikal 0.46 and use it mainly with iOS devices to sync a calendar and adressbook, which is working fine. I have set up Thunderbird to sync the adressbook with the sogo connector which also doesn't give me any problems, but I cannot get calendar sync to work with Lightning. The authentication process seems to work fine, but the content of the calendar doesn't get synced. Error log in thunderbird and also the server logs show a 500 response, when thunderbird sends the options command.

CalDAV: Status 207 on initial PROPFIND for calendar baikal
CalDAV: send: OPTIONS https://XXXXXXXXXX/baikal/html/dav.php/calendars/XXXX/
CalDAV: Unexpected status 500 while querying options baikal
[calCachedCalendar] replayChangesOn finished.
[calCachedCalendar] sync queue empty.

[pr3d4t0r]

Hej.

It looks like the calendar URI looks malformed; please try these:

https://calendar.server.yours/dav.php/calendars/yourBaikalUserName/calendarNameHere/

OR

https://calendar.server.yours/cal.php/calendars/yourBaikalUserName/calendarNameHere/

Lightning expects that you spell out each calendar. Also, the path to the resource should not include the /baikal/html sub-path.

Did you define the Apache or Nginx virtual (or actual) host for your server? Please cross-check against the Baïkal server installation instructions.

Cheers!

pr3d

[sirnone]

@pr3d4t0r used Version is 0.46 so the path is correct.

from Server Upgrade instructions

So two things changed:

cal.php, card.php moved into the html/ directory.
We added dav.php. cal.php and card.php still exist in the html/ directory but will be removed in a future version. dav.php is an endpoint for both caldav and carddav combined.

I can confirm to have the same problem on a Baikal 0.46 installation with Lightning!

[evert]

Hi @sirnone ,

Could you try opening the exact url you used for lighting in a browser? It should also pop up the username and password screen. Do you get a correct result?

@pr3d4t0r dav.php is indeed the correct endpoint now. The other two will be removed.

[jonasongithub]

Opening the url in a browser gives me the login prompt an then displays a list of files, so I guess that works fine. I also noticed that while the propfind command sent from lightning goes to the specified url, server logs show that the options command just goes to ../calendars/username so without the actual calendar name.

[evert]

This is all really odd and I wonder if it's caused by some configuration on the server interfering. OPTIONS should usually be pretty "simple" to handle.

Are you able to manually send the options request via the curl command line tool? I would be curious what the full response is. Example:

curl -v -X OPTIONS [url]

[jonasongithub]

* Rebuilt URL to: OPTIONS/
* Could not resolve host: OPTIONS
* Closing connection 0
curl: (6) Could not resolve host: OPTIONS

[evert]

you're missing the url part =)

[jonasongithub]

curl -v -X -k OPTIONS https://xxxxxxxxx/baikal/html/dav.php/calendars/xxxx/default
* Rebuilt URL to: OPTIONS/
* Could not resolve host: OPTIONS
* Closing connection 0
curl: (6) Could not resolve host: OPTIONS
*   Trying xxxxxxxxxx
* TCP_NODELAY set
* Connected to xxxxxxxxxx (xxxxxxxxxx) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: D:\Downloads\curl-7.50.2-win64-mingw\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 1
curl: (60) SSL certificate problem: unable to get local issuer certificate

i use a self signed certificate so curl can't verify it but that shouldn't be an issue with thunderbird since carddav sync works fine.

[evert]

The OPTIONS argument belongs to -X, not -k.

[jonasongithub]

D:\Downloads\curl-7.50.2-win64-mingw\bin>curl -v -k -X OPTIONS https://xxxxxxxxxxxx/baikal/html/dav.php/calendars/xxxxxxxxxxxx/default
*   Trying xxxxxxxxxxxx...
* TCP_NODELAY set
* Connected to xxxxxxxxxxx(xxxxxxxxxxxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=Zbox
*  start date: Feb 12 19:48:36 2016 GMT
*  expire date: Feb 12 00:00:00 2017 GMT
*  issuer: CN=Zbox
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x270bae28120)
> OPTIONS /baikal/html/dav.php/calendars/xxxxxxxxx/default HTTP/1.1
> Host: xxxxxxxxxx
> User-Agent: curl/7.50.2
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 401
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< content-type: application/xml; charset=utf-8
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< server: Microsoft-IIS/10.0
< set-cookie: PHPSESSID=4034fjeopsar0oifqv1487ctm5; path=/; HttpOnly
< www-authenticate: Basic realm="sabre/dav"
< date: Fri, 16 Sep 2016 16:57:23 GMT
< content-length: 354
<
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:sabredav-version>3.1.3</s:sabredav-version>
  <s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
  <s:message>No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured</s:message>
</d:error>
* Curl_http_done: called premature == 0
* Connection #0 to host xxxxxxxxxxxxx left intact

[evert]

There you go, getting a bit further :)

Next step would be to add --username [youruser]:[yourpassword]. This should at least fully reproduce the same request you originally had.

[jonasongithub]

D:\Downloads\curl-7.50.2-win64-mingw\bin>curl -v -k --user xxxxxx:xxxxxx -X OPTIONS https://xxxxxxxx/baikal/html/dav.php/calendars/xxxxxx/default
*   Trying xxxxxxxxxxxx...
* TCP_NODELAY set
* Connected to xxxxxxxxxxxx(xxxxxxxxxxxxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=Zbox
*  start date: Feb 12 19:48:36 2016 GMT
*  expire date: Feb 12 00:00:00 2017 GMT
*  issuer: CN=Zbox
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Server auth using Basic with user 'xxxxxxxxx'
* Using Stream ID: 1 (easy handle 0x1d956bc8120)
> OPTIONS /baikal/html/dav.php/calendars/xxxxxxxxx/default HTTP/1.1
> Host: xxxxxxxxxx
> Authorization: Basic am9uYXM6amR3ZGdscGJoMw==
> User-Agent: curl/7.50.2
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< allow: OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT
< content-length: 0
< content-type: text/html; charset=UTF-8
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< accept-ranges: bytes
< server: Microsoft-IIS/10.0
< set-cookie: PHPSESSID=31gitipjc77daqt01dvlh2njl4; path=/; HttpOnly
< x-sabre-version: 3.1.3
< dav: 1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, calendar-access, calendar-proxy, calendar-auto-schedule, calendar-availability, addressbook
< ms-author-via: DAV
< date: Fri, 16 Sep 2016 17:08:37 GMT
<
* Curl_http_done: called premature == 0
* Connection #0 to host xxxxxxxxxx left intact

[evert]

Hi @jonasongithub ,

That last request went through perfectly. To me that might suggest that there's a difference between that request and the original request you did via Lightning.

So a few questions:

1. Are you using the same url you used in lightning?
2. Are you using the same username and password?
3. Maybe something has changed in the meantime? Could you try setting up lightning again and see if you're getting an identical error as the first time you ran this?

[jonasongithub]

I use exactly the same url and username/password and nothing has changed since the last time. I just tried again anyway with the same result as before. The problem is also not new, before 0.4.6 i was on 0.2.7 for a while and lightning wouldn't work either.

[evert]

In that case I'm completely lost why OPTIONS works from your command-line, but not lightning. I have no idea how to go further from this. The only thing I have left to offer is me actually going into your server and try to see if I can reproduce and/or fix this (which I would be happy to do, just drop me an email).

Given that that's the case, I have no other option but to close this until there is more detailed information about why one fails and the other doesn't.