Dort werden beim Start von Thunderbird keine Terminserien synchronisiert (nur die einmaligen Termine).
Meinst du wirklich bei jedem Start von Thunderbird, oder nur beim ersten initialen Sync mit TbSync?
Ist das Problem vorher nicht aufgetreten und erst mit dem Update auf 0.7.16?
Das Problem ist mir bis jetzt unbekannt, was für ein Server ist das?
Mein aktueller Stand ist, dass outlook.com noch immer keine Kategorien unterstützt. Sorry.
VG
John
Wenn Ihr nicht so lange warten wollt, dann könnt ihr natürlich auch einfach die Beta-Version installieren:
Ich lade nach kurzer Testphase die aktuelle Version immer auch auf ATN (addons.thunderbird.net), aber dort dauert die Freischaltung leider immer etwas.
AHHHHHHHHH, es funktioniert bei mir mit OwnCloud wenn
network.cookie.cookieBehavior = 1
in den erweiterten Thunderbird-Einstellungen gesetzt wird. Woa, kannd as jemand bestätigen?
Die Einstellung besagt "reject all third-party cookies", was meine Vermutung bzgl. des fehlerhaften Cookie Managments unterstützen würde...
edvoldi Mir geht es gerade darum die Entwickler zu entlasten und ich wollte normale Benutzer um Hilfe bitten, den Trick mit https://username:password@server/path/to/caldav/addressbook mit aktuellen Servern zu testen. Wenn bei dem Test rauskommt, dass es wirklich nur am Cookie-Management liegt, hab ich einen konkreten Hinweis für die Entwickler.
Technisch vermute ich den Grund in dieser Datei:
https://dxr.mozilla.org/mozilla-centra…okieService.cpp
Hier wird nur der host und nicht der prePath (enthält auch username:password) als Identifier benutzt, sodass immer nur ein Cookie-Satz pro Server gespeichert wird. Eine Analyse des Traffics hat das auch gezeigt. Es kommen von den unterschiedlichen Verbindungen unterschiedliche Cookies rein, aber immer der letzte wird für alle kommenden ausgehenden Verbindungen benutzt. Damit nutzen alle Verbindungen die gleiche SessionID, was natürlich schief geht.
Ich vermute also, dass der Trick funktioniert, wenn der Server für die reine CalDAV Kommunikation ohne Cookies auskommt. Kann das jemand bestätigen?
Ich habe gerade diesen Faden gefunden:
Keinen zweiten GMX Kalender möglich
Dieser ist genau im Thema, daher denke ich, sollte dieser Faden hier geschlossen werden.
graba Sorry, ich hab den vorher nicht gefunden.
Hat sich hier etwas getan? Ich versuche gerade die Gründe dafür zu verstehen. Nachdem ich ein wenig durch den Code gestöbert habe, glaube ich, dass der Trick mit username:password in der URL nicht geht, wenn Sessions-Cookies zwingend notwendig sind, weil Thunderbird nur einen pro Server speichert.
Owncloud 10 soll aber inzwischen ohne Sessions-Cookies auskommen (benutzt dafür auth tokens). Kann das jemand bestätigen? Gibt es andere Server, die bei der reinen CalDAV Kommunikatin ohne Sessions-Cookies auskommen?
Für den Test müssen sowohl Benutzername als auch das Passwort in die URL, weil sonst ständig ein Passwort-Dialog angezeigt wird.
https://testuser1:password@cloud.server.de/remote.php/caldav/calendars/testuser1/work/
https://testuser2:password@cloud.server.de/remote.php/caldav/calendars/testuser2/work/
Ich suche Server, mit denen das klappt. Ich vermute, dass es nicht funktioniert, wenn zwingend Session-Cookies benutzt werden, wie bei älteren OwnCloud-Installationen.
Ich würde die Umfrage gern erweitern:
Gibt es Server, bei denen das überhaupt nicht funktioniert, also auch nicht mit einem Kalender, weil der Server mit dem zusätzlichen Benutzernamen in der URL nicht klar kommt?
Wegen einer Implementierungsschwäche ist es in Lightning nicht so ohne weiteres möglich, Kalender verschiedener Nutzer auf dem gleichen Server zu abonnieren. Das hier geht z.B. nicht:
https://cloud.server.de/remote.php/caldav/calendars/testuser1/work/
https://cloud.server.de/remote.php/caldav/calendars/testuser2/work/Nur einer der beiden Kalender wird synchronisieren. Das Problem liegt darin, das Lightning nicht speichert, welcher Benutzer zu einem Kalender gehört, sondern anhand das Base-Pfades sowohl den Benutzer als auch das Passwort aus dem PasswordManager holt. Beide Kalender oben haben den gleichen Base-Pfad (https://cloud.server.de) und daher geht das schief.
Durch Zufall bin ich aber darauf gestoßen, dass - zumindest Thunderbird 60.0 - in der URL auch ein Benutzernamen erlaubt ist:
https://testuser1@cloud.server.de/remote.php/caldav/calendars/testuser1/work/
https://testuser2@cloud.server.de/remote.php/caldav/calendars/testuser2/work/Dadurch haben beide URLs einen unterschhiedlichen Base-Pfad und der Passwort-Lookup im PasswordManager funktioniert.
Mit owncloud 8 geht das trotzdem nicht, da OwnCloud für beide Verbindungen den gleichen Session-Cookie zurückgibt und damit einer der beiden Kalender trotzdem falsch authorisiert wird.
Frage:
Gibt es andere Server, bei denen das funktioniert? OwnCloud 10 z.B. soll keine Session-Cookies mehr benutzen. Was ist mit reinen sabre/dav Servern? Oder Baikal?
Vielen Dank für Eure Mithilfe
John
Wäre es intuitiver, wenn eine solche Löschung auch automatisch das Abonnement beendet?
TbSync funktioniert hier etwas anders, evtl verwirrend.
Es synct immer alle abonnierten Ordner. Wenn du in Thunderbird ein Adressbuch löschst, dann ist es weiterhin abonniert, du hast nur das "Sync-Ziel" gelöscht. Beim nächsten Sync wird es wieder neu runtergeladen.
Dein "Löschen" hat hier keine Auswirkungen auf den Server, das war mir zu gefährlich.
Damit das Adressbuch nicht mehr runtergeladen wird, musst du es im TbSync Account Manager abwählen: Doppelklick oder Rechtsklick auf den entsprechenden Eintrag in der Ordner-Liste auf der rechten Seite.
Zum tatsächlichen Löschen des Adressbuchs musst du dich an dem Web-Interface von deinem Server anmelden.
Edit: Typos
Sorry für die Abkürzungen. AMO steht für addons.mozilla.org, dort gibt es die Addons, die durch das Mozilla Team geprüft und freigegeben wurden. Das lagen bis vor kurzem die offiziellen AddOns für Firefox und Thunderbird.
Vor ein paar Wochen hat sich Thunderbird hier aber von Mozilla getrennt und die AddOns liegen nun auf addons.thunderbird.net, was nun mit ATN abgekürzt wird.
VG
John
adir1 Hm, das ist komisch. Ich versuch mal was an TbSync zu ändern und schick dir dann eine Testversion.
Thunder Das ist nicht zu 100% korrekt, ich konnte das Problem durch Ändern der Mindestschriftgröße reproduzieren.
@adir Bitte wirklich mal die Mindesschriftgröße auf "keine" stellen und neu starten. Wenn das das Problem behebt, weiß ich wo ich ansetzen muss und kann es in der nächsten Version von TbSync reparieren.
GnOmE da muss ich passen. Ist das ein lokales "Systemadressbuch"?
TbSync kann nur mit externen Konten arbeiten, entweder via CardDAV/CalDAV oder EAS und bald hoffentlich auch EWS.
Lightning unterstützt den Discovery Service nicht, d.h. man muss die URL wissen, die zu einem Kalender gehört, um ihn einzutragen. TbSync macht genau das, es zeigt dir alle Kalender in deinem Account an und du kannst angeben, welche davon gesynct werden sollen.
Das syncen selber macht dann "wie üblich" Lightning, hier habe ich das CalDAV Protokoll nicht nochmal implementiertm sondern lasse Lightning syncen.
VG
John
Hast du TB schon neu gestartet nach der Änderung?