Lightning: CalDAV-Passwort wird nicht gespeichert

Wenn Sie plötzlich keine E-Mails mehr empfangen können

Bitte lesen Sie die Hinweise zu den beiden derzeit häufigsten Problemursachen!

Hier bitte klicken!

Diese rote Box verschwindet, wenn Sie in der rechten oberen Ecke auf das X klicken.

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

    • Thunderbird-Version: 68.4.1
    • Lightning-Version: 68.4.1
    • Betriebssystem + Version: Windows 10 Pro für Workstations V. 1903
    • Google-Kalender mit "Provider for Google-Calendar" (ja/nein): nein
    • Google- oder sonstiger Kalender mit WebDAV / CalDAV (ja/nein/was genau): CalDAV (Zoho)
    • Eingesetzte Antivirensoftware: Windows Defender
    • Firewall (Betriebssystem-intern/Externe Software): intern

    Nach der Neueinrichtung von TB und Lightning wird das Passwort für einen CalDAV-Kalender-Feed nicht mehr im Passwortmanager gespeichert, obwohl ich die Checkbox setze. Das Passwort ist auch korrekt, denn die Kalendereinträge erscheinen. Nach einem Neustart von TB wird jedoch erneut nach den Zugangsdaten zum Kalender gefragt.

    Die Add-Ons, mit denen man den Passwort Manager manuell editieren kann ("Saved Password Editor" sowie "Classic Password Editor"), sind noch nicht kompatibel mit der neuen TB-Version.

    Auch meine Recherche hat leider keine Lösung herbeigeführt. Ich hatte versucht, die Datei pkcs11.txt (https://support.mozilla.org/en-US/questions/1240420) bzw. key4.db (https://support.mozilla.org/en-US/questions/1145000) im Profilordner zu löschen, aber auch danach werden nur die IMAP/SMTP-Passwörter gespeichert und nicht das Kalenderpasswort. Das Passwort eines anderen CalDAV-Kalenders hingegen wird normal gespeichert.

    Weiß jemand eine Lösung oder muss ich warten bis die Passwort Editoren geupdatet werden? Danke im Voraus.

    Edited once, last by je1895 ().

  • Der Server, mit dem du dich verbinden willst, schickt in seinem WWW-Authenticate header keinen Realm (oder er ist leer). Siehe hier:
    https://developer.mozilla.org/…s/Web/HTTP/Authentication


    WWW-Authenticate: Basic realm="NextCloud"


    Der Password-Manager kann Passwörter nur speichern, wenn ein realm definiert ist, sonst kommt dein Fehler.


    Ist die Serverkonfiguration in deinem Zugriff? Oder kannst du jemanden kontaktieren?

  • Leider ist der Server nicht in meinem Zugriff, aber ich habe dem Anbieter (zoho.com) geschrieben. Die erste Antwort war, dass mit CalDav alles okay zu sein scheint. Nun habe ich nochmal nachgehakt, was mit dem realm ist, denn leider geht es immer noch nicht.


    Seit ein paar Tagen funktioniert es auch auf einem anderen Rechner nur für diese Kalender nicht mehr, obwohl das Passwort vorher wochenlang gespeichert war und funktionierte.


    Ich habe bei meiner Recherche noch einen weiteren Artikel gefunden, aber diesen Workaround finde ich ein wenig seltsam. Er funktioniert aber.

  • Der Anbieter hat seine Servereinstellungen überarbeitet und nun klappt das Speichern wieder. Der Tipp von jobisoft mit dem fehlenden "realm" gab den Ausschlag. Danke dafür.

  • Hallo,


    bei mir tritt exakt der gleiche Fehler auf, allerdings unter leicht anderen Voraussetzungen:


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

    • Thunderbird-Version: 78.4.2
    • Lightning-Version: 78.4.2
    • Betriebssystem + Version: Windows 10 Pro V. 2004
    • Google-Kalender mit "Provider for Google-Calendar" (ja/nein): nein
    • Google- oder sonstiger Kalender mit WebDAV / CalDAV (ja/nein/was genau): CalDAV (Nextcloud)
    • Eingesetzte Antivirensoftware: Windows Defender
    • Firewall (Betriebssystem-intern/Externe Software): intern

    Fehlermeldung beim Anlegen eines neuen Kalenders (Checkbox zum Speichern der Daten ist gesetzt):


    Ich hatte vorher eine Owncloud-Instanz, mit der es (vermutlich aufgrund einer sehr alten und daher kompatiblen Konfiguration) nie Probleme gab. Die Fehlermeldung stammt von einer frisch aufgesetzten Nextcloudinstanz mit folgender apache2-Serverkonfiguration:

    Leider suche ich mich gerade taumelig, wie ich genau den offensichtlich fehlenden realm eintragen soll... Kann hier jemand helfen?

    Der Tip von @JE1985 (im Link wird vorgeschlagen, user/Passwort beim Anlegen des Kalenders via

    https://<username>:<password>@<caldav address>

    zu setzen) umgeht das Problem nur teilweise - hier wird das Passwort nicht im Passwortmanager gespeichert, sondern im Link. Das funktioniert leider nur dann, wenn man bestimmte Sonderzeichen im Passwort vermeidet (z.B. ?/). Hierauf möchte ich aber nicht verzichten, sonst werden die Passwörter bei gleicher Stärke viel zu lang, um sie sich noch merken zu können.

    Die Tips von hier (http/2 zu deaktivieren - also in der Konfiguration oben die Zeile "protocols h2" zu entfernen; alle Passwörter löschen und neu anlegen) helfen ebenfalls nicht weiter.


    Wenn man ein CardDAV-Konto von besagter Nextcloud-Instanz mit besagtem Nextcloud-Nutzer importiert, wird das Passwort gespeichert. Allerdings hilft das nicht für die CalDAV-Konten, ich werde dennoch bei jedem Neustart nach einem Passwort gefragt...

    Edited 2 times, last by ssdnvv: Korrekturen durchgeführt ().

  • Komisch ist, dass es laut Fehlermeldung keinen Realm gibt, die Verbindung auf die NC aber über CardDAV klappt. Nutzt du dafür TBSync oder Cardbook?


    Da es nur den Kalender betrifft, versuche mal im Thunderbird calendar.network.multirealm;true. Das passt für mich zwar auch nicht wirklich zu der Fehlermeldung, aber einen Versuch ist es wert. Wenn er nicht fruchtet, stelle den Wert wieder auf false und warte mal, ob jobisoft weiterhelfen kann.

  • Mein eigene CardDAV Implementierung nutzt den Realm nicht zur Password-Hinterlegung. Das Problem ist die (Standard-) Implementierung der Password-Hinterlegung von Lightning, die zwingend einen Realm braucht. Deswegen geht CalDAV nicht ohne Realm. Dem Server ein Realm zu verpassen geht nicht?

  • Da es nur den Kalender betrifft, versuche mal im Thunderbird calendar.network.multirealm;true

    Danke, werde ich später ausprobieren.


    Dem Server ein Realm zu verpassen geht nicht?

    Das wäre genau meine Fragestellung wie man das umsetzt. Habe mich da gestern ohne Erfolg taumelig gesucht.

    Bei der Doku von apache2 direkt findet man realm nur im Kontext von htaccess, was hiermit nichts zu tun hat. Und sonst ist mit Antworten mau - vermutlich verwende ich den falschen Suchbegriff... Ich denke ebenfalls, dass die Implementierung von Lightning hier das Problem ist, denn bei cardbook scheint es ja auch zu funktionieren :/

  • htaccess ist jetzt nicht sooo falsch. Du musst gucken, wer die Authentifizierung von GET/PUT/PROPFIND requests auf deinen caldav endpunkt verwaltet und der macht vermutlich HTTP BASIC AUTH und da muss der realm definiert werden.

  • Dem Server ein Realm zu verpassen geht nicht?

    Sicherlich irgendwo im Apache. Aber ich habe bisher gedacht, das sein nur nötig, wenn man SSO, LDAP, Kerberos, ... verwendet. Ich habe mich aus gutem Grund für die vorkonfigurierte Version der NC entschieden. Die funktioniert out of the box und muss lediglich zum Optimieren angepasst werden (sowas wie Logs in RAM, Speicherort für Datenbank verschieben, automatisches Backup usw. .). :)

  • und der macht vermutlich HTTP BASIC AUTH und da muss der realm definiert werden.

    Das könnte eine weitere Fehlerquelle sein. Wenn ich mich richtig erinnere, dann wird (wurde?) unter Windows im Gegensatz zum Linux und Mac bei BASIC nur https unterstützt.


    Ich geh stark davon aus, das bei dir irgendwas nicht korrekt konfiguriert wurde.

    Na, bei mir funktioniert alles wie geölt.

  • Mein out-of-the-box NC hat nen realm.

    Meiner auch.

    Code
    REPORThttps://.../remote.php/dav/calendars/...[...]
    Antwortkopfzeilen (1,149 KB)
    [...]
    Authorization: Basic ...
    [...]


    Ist aber vorkonfiguriert, sprich, ich weiß nicht, wie man den setzt.


    das kann auch https

    Ja, ich meine sogar nur https. Hab's in meinen Bookmarks auch wiedergefunden. Schau mal hier https://www.digitalocean.com/c…th-apache-on-ubuntu-14-04


    im Abschnitt "Basic or Digest Authentication?" Dieser Artikel war für mich einer der Gründe, auf die ootb-Lösung zu gehen, weil mir das mit dem Apache zu heftig schien.


    Quote

    If you are using HTTP, use Digest authentication as it will work on all operating systems. If you are using HTTPS, you have the option of using Basic authentication.

  • Da es nur den Kalender betrifft, versuche mal im Thunderbird calendar.network.multirealm;true. Das passt für mich zwar auch nicht wirklich zu der Fehlermeldung, aber einen Versuch ist es wert.

    Es hat funktioniert - was ich oben vergessen hatte zu erwähnen, ist dass ich drei verschiedene Benutzer-/Passwortkombinationen sowie diverse Kalender pro Kombination habe. In meiner vorherigen Owncloud-Instanz hatte ich nur einen einzigen Nutzer, jetzt muss ich ein paar mehr Kalender im Blick behalten (die Familie ist gewachsen ^^). Somit ist bei mir schon alles korrekt konfiguriert gewesen, ich war mir nur der Standardeinstellungen von Thunderbird diesbezüglich nicht bewusst.