Keinen zweiten GMX Kalender möglich

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version: 52.8
    • Lightning-Version: 5.4
    • Betriebssystem + Version: Ubuntu 18.04 LTS

    Hallo,

    ich habe 2 GMX Konten in Thunderbird eingerichtet.

    Kontakte konnte ich schon per Cardbook einbinden, da SoGo wohl kein GMX mag.

    Allerdings wird beim zweiten Kalender kein PW Dialog angezeigt, um sich anzumelden.

    Deshalb funktioniert derzeit nur der 1. Kalender.

    Lightning und SoGo Connector ist bereits installiert.

    CALDAV: https://kalender.gmx.net/begenda/dav/ma…mx.de/calendar/

    Aktivieren kann ihn nicht, da er kurz darauf sich wieder deaktiviert.

    Wo liegt mein Fehler?

    Vielen Dank!

    Viele Grüße

    Revan335

    Einmal editiert, zuletzt von Revan335 (21. Juni 2018 um 00:05)

  • Thunder 21. Juni 2018 um 00:06

    Hat das Thema freigeschaltet.

    Siehe mehrere PW-Geschützte Kalender unter gleicher Domain und auch den dort genannten Bug.

    Man findet im Internet Berichte, wonach die Lösung mit calendar.network.multirealm=true bei einigen funktioniert, bei anderen anscheinend nicht. Der Grund für das unterschiedliche Verhalten ist mir nicht bekannt.

    Ich würde es deshalb mit einem neuem Profil testen und sofort diesen Schalter setzen. Dann den Thunderbird neu starten und erst danach die Konten einrichten.

    Sollte es nicht funktionieren, bliebe die oben ebenfalls erwähnte Möglichkeit, den Kalender per http(s)://benutzername:passwort@adresse anzusprechen.

    Der SOGo-Connector wird nicht benötigt.

    Zitat von Revan335

    multirealm scheint nicht zu klappen.

    Wie erwähnt, funktioniert es bei manchen, bei anderen nicht. Ob das vom Provider abhängt oder davon wann multirealm gesetzt wird, entzieht sich meiner Kenntnis. Deshalb hatte ich empfohlen, den Weg über ein neues Profil zu gehen und die Konten erst dann einzurichten, nachdem multirealm umgestellt und der Thunderbird neu gestartet wurde.

    Hast du das so durchgeführt?

    Zitat von Revan335

    Mit der URL: https://max.mustermann@gmx.de:Passwort@https://www.gmx.net/kalender.gmx.n…mx.de/calendar/


    Geht es leider nicht.

    Die URL sieht nicht korrekt aus. Nach dem zweiten "@" sollte kein "https://www" mehr auftauchen sondern nur die Serveradresse, hier kalender.gmx.net/begenda/...

    Das Verfahren, das Passwort gleich in der URL mitzusenden, sollte grundsätzlich funktionieren. Wirklich empfehlenswert ist diese Art jedoch ohnehin nicht.

    Ich kann bzw. mag das in Hinblick auf die korrekte Adresse nicht selbst testen, weil ich mir dazu ein weiteres Konto und die dazugehörigen Kalender bei gmx einrichten müsste.

    Es gibt hier gewiss andere, die zwei oder mehr Konten bei gmx haben. Vielleicht melden die sich dazu zu Wort.

    Last but not least: Ich habe hier im Forum noch eine recht elegante Art gefunden, das Problem zu lösen. Es handelt sich nur um einen workaround, aber ziemlich clever gemacht von herzAG : Lightning mehrere GMX Kalender, Zertifikatsfehler

    Ich würde mich dennoch freuen, wenn jemand, der Kontakt zu den Entwicklern hat, dieses Thema abschließend klären könnte. Es taucht schließlich immer wieder einmal auf.

    Mich auch.

    Dann könnte man eine Doku dazu machen.

    Und sagen wenn ihr dies so macht, dann funktioniert die Synchronisierung mit Anbieter xyz.

    Kann man dann ggf. um weitere Anbieter erweitern.

    Für Posteo könnte ich dies bspw. erstellen.

    Ich müsste dann nur wissen wo/wie ich das erstellen soll, dann kann ich mit bspw. Posteo starten und wir können es dann mit GMX und Co. erweitern.

    Hallo Solaris,

    Zitat von Solaris

    Ich würde mich dennoch freuen, wenn jemand, der Kontakt zu den Entwicklern hat, dieses Thema abschließend klären könnte. Es taucht schließlich immer wieder einmal auf.

    ich habe Philipp einmal abgeschrieben, schauen wir mal ob er Antwortet.

    Gruß EDV Oldi vom Smartphone

    Entschuldigung, die Nachricht von Philipp ist wieder im Spam gelandet, darum erst jetzt seine Antwort.

    Zitat


    Gruß
    EDV-Oldi

    Vielen Dank edvoldi und natürlich an Philipp.

    Nun scheint auch klar, weshalb multirealm bei einigen funktioniert und bei anderen nicht.

    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?

    Hallo zusammen,

    ich würde diese Diskussion hier:

    https://groups.google.com/forum/#!forum/…v.apps.calendar

    weiter führen, hier lesen die Entwickler auch mit.


    Gruß
    EDV-Oldi

    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?

    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...

    Nachdem mich dieses Thema jetzt ein halbes Jahr umgetrieben hat, hab ich endlich die Lösung für das Problem gefunden. Wer die technischen Details wissen will, kann sich gern durch bug 1494955 arbeiten.

    Ich hab das in der aktuellen Beta von TbSync gefixt und auch einen Patch für Lightning fertig gemacht und eingeschickt. Ich hoffe der wird bald akzeptiert.

    Wer das jetzt schon ausprobieren will, kann das gepatchte Lightning aus diesem Repository beziehen:

    https://github.com/jobisoft/lightning625/releases/

    Wer will, kann da auch die Änderungen nachvollziehen.

    Es wäre tatsächlich schön, wenn das jemand (außer mir) ausprobiert, um mögliche Fehler vor dem Release zu finden.

    jobisoft: ich hatte das Problem mit Synology Calendar und getrennten CalDav Accounts in Thunderbird Lightning und konnte es dank Deiner gepatchten Version 6.2.5.1 mit eigenen Benutzernamen lösen. Die Syncs laufen ohne Probleme. Vielen Dank.

    *tada* Mein Patch wurde akzeptiert und mit Thunderbird 68 Beta 2 ist dieses Problem endlich aus der Welt.

    Externer Inhalt raw.githubusercontent.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

    Zu jedem CalDAV Kalender kann nun ein Benutzername definiert werden und intern haben die Verbindungen zum gleichen Server nun jeweils einen eigenen Cookie-Speicher, sodass es da nicht mehr zu Störungen kommt.