Open Xchange bietet CalDAV Dienst je nach Header

open-xchange
german

#1

Hallo,

ich wollte mein Android Kalender über CalDAV mit dem Kalender von Open Xchange synchronisieren.

Die App DavDroid ist mein Favorit.

Leider findet DavDroid keinen CalDAV Dienst:

[code]2016-06-01 10:42:00 5 [ui.setup.DavResourceFinder] Finding initial carddav service configuration
2016-06-01 10:42:00 5 [ui.setup.DavResourceFinder] Checking user-given URL: https://144.76.XXX.XXX/caldav/41
2016-06-01 10:42:00 5 [HttpClient$1] --> PROPFIND https://144.76.XXX.XXX/caldav/41 http/1.1
2016-06-01 10:42:00 5 [HttpClient$1] Content-Type: application/xml; charset=utf-8
2016-06-01 10:42:00 5 [HttpClient$1] Content-Length: 290
2016-06-01 10:42:00 5 [HttpClient$1] Depth: 0
2016-06-01 10:42:00 5 [HttpClient$1]
2016-06-01 10:42:00 5 [HttpClient$1] <?xml version='1.0' encoding='UTF-8' ?><CARD:addressbook-description /><CARD:addressbook-home-set />
2016-06-01 10:42:00 5 [HttpClient$1] --> END PROPFIND (290-byte body)
2016-06-01 10:42:00 5 [HttpClient$1] <-- 405 Method Not Allowed https://144.76.XXX.XXX/caldav/41 (252ms)
2016-06-01 10:42:00 5 [HttpClient$1] Date: Wed, 01 Jun 2016 08:42:03 GMT
2016-06-01 10:42:00 5 [HttpClient$1] Server: Apache/2.2.22 (Univention)
2016-06-01 10:42:00 5 [HttpClient$1] Allow: GET,HEAD,POST,OPTIONS
2016-06-01 10:42:00 5 [HttpClient$1] Vary: Accept-Encoding
2016-06-01 10:42:00 5 [HttpClient$1] Keep-Alive: timeout=5, max=100
2016-06-01 10:42:00 5 [HttpClient$1] Connection: Keep-Alive
2016-06-01 10:42:00 5 [HttpClient$1] Content-Type: text/html; charset=iso-8859-1
2016-06-01 10:42:00 5 [HttpClient$1]
2016-06-01 10:42:00 5 [HttpClient$1]

405 Method Not Allowed

Method Not Allowed

The requested method PROPFIND is not allowed for the URL /caldav/41.


Apache/2.2.22 (Univention) Server at 144.76.230.31 Port 443 [/code]

(Ich hab den Fehlerlog mal gekürzt, auf jeden Fall findet DavDroid keinen CalDAV Dienst unter den Standard URLs)

Auch mit einem neuen Testaccount und über curl wurde nichts gefunden:

[code]$ curl -kvX OPTIONS --user ‘USER:PASSWORT’ https://144.76.XXX.XXX/caldav/63

  • Trying 144.76.XXX.XXX…
  • Connected to XXX.de (144.76.XXX.XXX) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • skipping SSL peer certificate verification
  • ALPN/NPN, server did not agree to a protocol
  • SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • Server certificate:
  • subject: E=ssl@XXX.de,CN=XXX.de,OU=Univention Corporate Server,O=XXX XXX,L=DE,ST=DE,C=DE
  • start date: Feb 11 09:45:34 2016 GMT
  • expire date: Feb 09 09:45:34 2021 GMT
  • common name: XXX.de
  • issuer: E=ssl@XXX.de,CN=“Univention Corporate Server Root CA (ID=XXX)”,OU=Univention Corporate Server,O=XXX,L=DE,ST=DE,C=DE
  • Server auth using Basic with user ‘davdroid-test’

OPTIONS /caldav/63 HTTP/1.1
Host: XXX.de
Authorization: Basic XXXXXX
User-Agent: curl/7.43.0
Accept: /

< HTTP/1.1 200 OK
< Date: Sat, 04 Jun 2016 09:30:44 GMT
< Server: Apache/2.2.22 (Univention)
< Allow: GET,HEAD,POST,OPTIONS
< Content-Length: 0
<

  • Connection #0 to host XXX.de left intact[/code]

Aber der Sync mit Mozilla Lightning hat funktioniert, also hab ich mal den Mozilla Header miteingefügt und siehe da:

[code]$ curl -kvX OPTIONS -H “User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 Lightning/4.7.1” --user ‘USER:PASSWORT’ https://XXX.de/caldav/

  • Trying 144.76.XXX.XXX…
  • Connected to XXX.de (144.76.XXX.XXX) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • skipping SSL peer certificate verification
  • ALPN/NPN, server did not agree to a protocol
  • SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • Server certificate:
  • subject: E=ssl@XXX.de,CN=XXX.de,OU=Univention Corporate Server,O=XXX,L=DE,ST=DE,C=DE
  • start date: Feb 11 09:45:34 2016 GMT
  • expire date: Feb 09 09:45:34 2021 GMT
  • common name: XXX.de
  • issuer: E=ssl@XXX.de,CN=“Univention Corporate Server Root CA (ID=XXX)”,OU=Univention Corporate Server,O=XXX,L=DE,ST=DE,C=DE
  • Server auth using Basic with user ‘USER’

OPTIONS /caldav/ HTTP/1.1
Host: XXX.de
Authorization: Basic XXX
Accept: /
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 Lightning/4.7.1

< HTTP/1.1 200 OK
< Date: 2016-06-04T12:54:34Z
< Server: Openexchange WebDAV
< Allow: GET,PUT,DELETE,HEAD,OPTIONS,TRACE,PROPPATCH,PROPFIND,MOVE,COPY,LOCK,UNLOCK,REPORT,ACL,MKCALENDAR
< DAV: 1, 2, 3, access-control, calendar-access, addressbook, extended-mkcol, calendar-auto-schedule, calendar-schedule, calendarserver-sharing, calendarserver-principal-search, calendarserver-principal-property-search, calendarserver-private-comments, extended-mkcol, calendar-managed-attachments
< Accept-Ranges: bytes
< MS-Author-Via: DAV
< Content-Length: 0
< Via: 1.1 XXX.de[/code]

Demnach hängt es vom Header ab ob Open Xchange einen CalDAV Dienst bietet oder nicht.

Ist diese Angewohnheit so gewollt und wenn ja mit welcher Begründung? Denn damit sperrt der Open Xchange Kalender DavDroid aus was für mich jetzt heißt eine andere CalDAV App zu finden


#2

Hallo,
ich bin jetzt überfragt, wie genau die Apache Konfiguration im UCS aussieht.
Dort wäre nämlich zu finden, unter welchen URLs CalDAV zur Verfügung gestellt wird.

Immer funktionieren sollte
HOST/servlet/dav/$CALENDAR-ID

Lt. oxpedia.org/wiki/index.php?title … figuration gibt es verschiedene Möglichkeiten, wie Apache konfiguriert werden kann.

Evtl. greift hier ein Rewrite für Lightning aber nicht für DavDroid?

Aber kurzer Tipp nach persönlicher Erfahrung: Ich glaube, DavDroid unterstützt noch immer keine Serien-Ausnahmen. Als ich damals einige CalDAV Sync Apps ausprobiert habe, habe ich nur play.google.com/store/apps/deta … .lib&hl=de für Serienausnahmen funktionierend gefunden.


#3

UCS konfiguriert in der UCR-Variablen ox/caldav/useragent/whitelist eine Liste von UserAgent-Strings die von Apache auf den caldav-Service von OX umgelenkt werden. Ich vermute der Grund ist, das die Autoerkennung der Clients mit anderen URLs auf UCS Servern kollidiert.


#4

Habs jetzt am laufen, hier das diff:

[code]------------------------------

root@univention:/etc/apache2/sites-available# diff -C 3 ox.old ox
*** ox.old 2016-06-06 20:46:43.426988000 +0200
— ox 2016-06-06 20:47:24.530988000 +0200


*** 41,46 ****
— 41,47 ----
RewriteCond %{HTTP_USER_AGENT} AddressBook [OR]
RewriteCond %{HTTP_USER_AGENT} Address%20Book [OR]
RewriteCond %{HTTP_USER_AGENT} CalendarStore [OR]


[/code]

Und schon gehts :smiley:

Wäre natürlich schön wenn Univention diesen User Agent noch zur Standard Konfiguration hinzufügt.


#5

DAVdroid unterstützt sich wiederholende Termine und auch Ausnahmen dafür. Natürlich kann es immer Probleme geben und manche Server liefern auch definitiv falsche RECURRENCE-IDs, aber prinzipiell funktioniert das. Bei diesbezüglich Problemen, die wahrscheinlich an DAVdroid liegen (also wenn RECURRENCE-ID stimmt), bitte im DAVdroid-Forum posten, danke.


#6

[quote=“Ikebana”]Habs jetzt am laufen, hier das diff:

[code]------------------------------

root@univention:/etc/apache2/sites-available# diff -C 3 ox.old ox
*** ox.old 2016-06-06 20:46:43.426988000 +0200
— ox 2016-06-06 20:47:24.530988000 +0200


*** 41,46 ****
— 41,47 ----
RewriteCond %{HTTP_USER_AGENT} AddressBook [OR]
RewriteCond %{HTTP_USER_AGENT} Address%20Book [OR]
RewriteCond %{HTTP_USER_AGENT} CalendarStore [OR]


[/code]

Und schon gehts :smiley:

Wäre natürlich schön wenn Univention diesen User Agent noch zur Standard Konfiguration hinzufügt.[/quote]

Besser als die Datei direkt anzupassen, ist es die UCR Variable “ox/caldav/useragent/whitelist” entsprechend zu erweitern. Diese Datei wird aus einem UCR Template generiert. Das bedeutet das Ihre Änderung ggf. wieder überschrieben wird (das Template liegt unter /etc/univention/templates/files/etc/apache2/sites-available/ox und ist an eine Reihe von UCR Variablen gebunden, ändert sich eine solche Variable, dann wird /etc/apache2/sites-available/ox aus dem Template neu erzeugt)

ucr get ox/caldav/useragent/whitelist ucr set ox/caldav/useragent/whitelist='...Alles was schon vorher gesetzt war...|DAVdroid'

Ich werde einen Bug anlegen, damit DAVdroid in der Standardeinstellung von “ox/caldav/useragent/whitelist” landet.

Viele Grüße
Felix


#7

Ok. Meine Tests habe ich 2014 gemacht. Damals ziemlich sicher auch ein Issue dafür aufgemacht oder gefunden aber nachdem die Historie nicht mehr auf Github liegt, finde ich leider keine Referenz mehr.
Wenn das jetzt funktioniert, umso besser.


#8

DAVdroid ist seit Juli 2016 standardmäßig in der Apache whitelist UCR variablen.


#9

Ich glaube, ich kann mich wieder erinnern, was das Problem war: Serienausnahmen werden von OX im gleichen CalDAV “File”, wie das normale Terminobjekt übermittelt. DAVdroid konnte allerdings (zumindest damals) mit Files mit mehreren Objekten nicht umgehen, so dass Ausnahmen nie im Client angekommen sind. Ich hatte damals versucht, die Spec zu verstehen und ich glaube, das ist so erlaubt, während die Bibliothek, die DAVdroid (und auch andere Apps) verwenden bzw. verwendet haben, das nicht korrekt parsen konnte.