Memories

Memories / Dokumentation

Auf dieser Seite

Autorisierung für OneDrive und Google Drive

Die CLI unterstützt die Anmeldung im Browser, die verschlüsselte lokale Speicherung von Konten, Statusabfragen, die lokale Abmeldung und cloud sync für unveränderliche Chiffretextobjekte über die Anwendungsordner von OneDrive oder Google Drive. Aktualisierte Tokens werden vor nachfolgenden Uploads dauerhaft gespeichert. Die Verifizierung mit echten Konten steht noch aus. Auf jedem Gerät kann pro Anbieter ein Konto verbunden werden; eine erneute Anmeldung ersetzt das Konto dieses Anbieters erst, nachdem die neue Autorisierung erfolgreich war.

Vor der Anmeldung

Erstellen/installieren Sie die neue CLI und starten Sie den Daemon mit derselben neuen Version neu:

cargo install --path crates/cli --locked
memories daemon

Führen Sie den Daemon in einem separaten Terminal aus. Entsperren Sie bei Bedarf Ihre vorhandene Bibliothek in dem Terminal, in dem die Anmeldung erfolgen soll, und führen Sie anschließend memories sudo aus. Verwenden Sie für jeden Befehl dasselbe --home/MEMORIES_HOME. Eine neue Bibliothek benötigt zuerst memories init. Verschieben Sie ihre Datenbank nicht in ein mit der Cloud synchronisiertes Verzeichnis.

OAuth-Anwendungsregistrierungen werden nicht mitgeliefert. Verwenden Sie Ihre eigenen Registrierungen; die CLI fragt niemals nach dem Passwort Ihres Microsoft- oder Google-Kontos. Authentifizierung und Zustimmung erfolgen auf der Website des Anbieters in Ihrem Browser.

OneDrive-Registrierung

  1. Erstellen Sie in Microsoft Entra ID eine App-Registrierung. Wählen Sie die Unterstützung für Konten in einem beliebigen Organisationsverzeichnis und persönliche Microsoft-Konten, wenn Sie sowohl geschäftliches als auch persönliches OneDrive benötigen. Dieser Client verwendet den Mandanten common.
  2. Fügen Sie unter „Authentifizierung“ eine Plattform Mobile und Desktopanwendungen mit der Umleitungs-URI http://localhost/oauth/callback hinzu. Dies ist ein öffentlicher Desktopclient, keine Web- oder SPA-Anwendung. Erstellen Sie für diesen Ablauf kein Clientgeheimnis.
  3. Konfigurieren Sie die delegierten Microsoft Graph-Berechtigungen User.Read und Files.ReadWrite.AppFolder; bei der Anmeldung wird außerdem offline_access angefordert. Die Zustimmungsrichtlinie einer Organisation kann eine Genehmigung durch einen Administrator erfordern.
  4. Kopieren Sie die Anwendungs-ID (Client-ID) und führen Sie Folgendes aus:
memories sudo
memories cloud login onedrive --client-id YOUR_MICROSOFT_CLIENT_ID

Der Callback verwendet http://localhost:PORT/oauth/callback. Microsoft ignoriert den Port beim Abgleich von localhost-Umleitungs-URIs; der Pfad muss mit der Registrierung übereinstimmen. Der Listener bindet ausschließlich an IPv4-Loopback. Mit dem optionalen --port PORT wählen Sie einen festen Port; andernfalls wählt das Betriebssystem einen freien Port.

Alternativ akzeptiert --client-config PATH ein JSON-Objekt mit client_id. Benutzerdefinierte Autorisierungs-/Token-URLs und Geheimnisse vertraulicher Clients werden nicht akzeptiert.

Google Drive-Registrierung

  1. Erstellen/wählen Sie ein Google Cloud-Projekt und aktivieren Sie die Google Drive API.
  2. Konfigurieren Sie den OAuth-Zustimmungsbildschirm. Wenn sich die App im Testmodus befindet, fügen Sie Ihr Google-Konto als Testnutzer hinzu. Fordern Sie drive.appdata sowie openid, email und profile zur Kontoidentifizierung an.
  3. Erstellen Sie einen OAuth-Client vom Typ Desktop-App und laden Sie dessen JSON-Datei herunter. Die CLI erwartet den heruntergeladenen Abschnitt installed, keine Webclient-Konfiguration.
  4. Bewahren Sie die JSON-Datei außerhalb dieses Repositorys auf und führen Sie Folgendes aus:
memories sudo
memories cloud login google-drive --client-config /path/to/google-desktop-client.json

Beispiel für Windows CMD:

memories cloud login google-drive --client-config "%USERPROFILE%\Downloads\google-desktop-client.json"

Der Callback verwendet http://127.0.0.1:PORT/oauth/callback. Der Ablauf für Desktopanwendungen unterstützt Loopback-Callbacks; ein gehosteter Callbackserver ist nicht erforderlich. Heruntergeladene Endpunktfelder werden ignoriert: Der Client verwendet feste offizielle Google-Endpunkte. Das Clientgeheimnis der installierten App wird, sofern angegeben, aus der JSON-Datei gelesen, niemals aus einem Befehlsargument. Geheimnisse von Desktop-Apps sind kein Ersatz für PKCE.

Google kann Aktualisierungstokens für Anwendungen im Testmodus ablaufen lassen (üblicherweise nach sieben Tagen, wenn nicht grundlegende Berechtigungsbereiche angefordert werden). Autorisieren Sie die Anwendung bei Bedarf erneut; die Anforderungen für Veröffentlichung und Anbieterprüfung hängen von Ihrer Anwendung ab.

Status, Abbruch und Abmeldung

memories cloud status
memories cloud sync onedrive
memories cloud sync google-drive
memories sudo
memories cloud logout onedrive
memories cloud logout google-drive

Der Status liefert Anbieter, Kontoidentität, Anzeigename/E-Mail-Adresse, Ablaufzeit des Zugriffstokens und die Information, ob ein Aktualisierungstoken gespeichert ist. Er liefert niemals Zugriffstokens, Aktualisierungstokens oder Clientgeheimnisse. sync_enabled zeigt an, dass mindestens ein Cloudkonto verbunden ist. object_sync meldet nur die Anzahl der Einträge in Ausgangs-/Eingangswarteschlangen. cloud sync aktualisiert Tokens bei Bedarf vor Übertragungen zum Anbieter; ein abgelaufenes Zugriffstoken allein bedeutet nicht, dass die Zustimmung beim Anbieter widerrufen wurde. Die Ablaufzeit wird vorsichtig ab Beginn des Tokenaustauschs berechnet; langsame Netzwerkantworten oder Abfragen des Kontoprofils verlängern die Tokengültigkeit nicht.

Die Abmeldung entfernt das lokale Konto und bricht jede ausstehende Anmeldung für diesen Anbieter ab. Sie widerruft die Zustimmung auf den Servern von Microsoft oder Google nicht. Verwenden Sie für einen entfernten Widerruf die Einstellungen des Anbieters für verbundene Apps. Das Entfernen lokaler Datensätze garantiert auch keine forensische Löschung aus Speichersnapshots oder älteren lokalen Kopien.

Die Anmeldung ist auf fünf Minuten begrenzt. --no-browser gibt die Autorisierungs-URL aus, ohne den Browser zu öffnen, wartet aber weiterhin auf einen Callback auf diesem Computer. Dies ist kein Out-of-Band-Ablauf mit manuell eingegebenem Code und kein Mechanismus zur Anmeldung auf entfernten Systemen oder ohne grafische Oberfläche. Bei einer Zeitüberschreitung oder einem normalen Fehler bricht die CLI ihr ausstehendes Ticket ab. Warten Sie nach einem erzwungenen Beenden der CLI bis zum Ablauf oder verwenden Sie vor einem erneuten Versuch cloud logout PROVIDER.

Sicherheit und Lebenszyklus

  • OAuth verwendet den Autorisierungscode mit S256 PKCE und einen unvorhersehbaren Zustandswert. Callback-Methode, Host, Ursprung, Pfad, doppelte Felder, Zustand, Ablauf und Wiederholung werden geprüft. Anbieterfehler und Callbackseiten geben keine Codes oder Tokens zurück.
  • Das Warten auf den Browser, der Tokenaustausch und Identitätsabfragen laufen im CLI-Prozess außerhalb des Mutex des Daemons und der Datenbanktransaktionen. HTTPS-Anfragen haben begrenzte Zeitüberschreitungen/Antwortgrößen, deaktivieren automatische Weiterleitungen und übernehmen keine Proxys aus der Umgebung. Netzwerkumgebungen, die einen Proxy erfordern, werden von dieser anfänglichen Transportkonfiguration nicht unterstützt.
  • Der Daemon stellt ein kurzlebiges Ticket aus, das an Anbieter, Client-ID und lokalen Aufrufer gebunden ist. Das Speichern erfordert erneut sudo; Sperren, Neustarten oder Abmelden macht ausstehende Tickets ungültig. Ein verspätetes HTTP-Ergebnis kann eine abgebrochene Anmeldung nicht wiederherstellen.
  • Der lokalen CLI wird vertraut, den Austausch mit dem Anbieter durchzuführen. Der Vorgang des Dienstes zum Schreiben von Tokens erfordert ein gültiges Ticket und erhöhte Berechtigungen; er ist kein entfernter Endpunkt und kann nicht durch MCP verwendet werden. Es gibt keinen Befehl zum Lesen von Tokens.
  • Konten und Tokens befinden sich im verschlüsselten lokalen Zustand. Sie sind von exportierten Sicherungen, Gerätefreigabe, Tresorsynchronisierung, Audit-Ausgabe und MCP ausgeschlossen. Jedes Gerät muss sich separat anmelden. Die Cloudanmeldung gewährt keine Tresormitgliedschaft.
  • Geheime Daten in Puffern mit eigener Speicherverantwortung werden mit Nullen überschrieben; HTTP-/URL-/JSON-Bibliotheken und der Betriebssystemspeicher können vorübergehende Kopien behalten, wie in SECURITY.md beschrieben.

Wenn das Zustandsfeld fehlt, bleibt die Abwärtskompatibilität gewahrt. Öffnen und schreiben Sie einen autorisierten Speicher nicht mit einem älteren Daemon erneut: Er versteht Cloudkonten nicht und kann das neue Feld verwerfen, sodass eine erneute Cloudanmeldung erforderlich wird.

Umfang der Validierung

Tests prüfen beide Anbieteraustauschvorgänge anhand lokaler HTTP-Testdaten, echte Loopback-Callbacks, verschlüsselte dauerhafte Speicherung, Bindung an den Aufrufer, Wiederholung, Abbruch nach dem Sperren, fehlende Berechtigungsbereiche/ Aktualisierungstokens, Schwärzung von Fehlern, Ausschluss aus Sicherungen und Verweigerung des MCP-Zugriffs. Der Testtransport ist ausschließlich innerhalb des Moduls verfügbar; Produktionsendpunkte sind feste HTTPS-Endpunkte.

Die Autorisierung mit echten Konten erfordert registrierte Client-IDs/ Konfigurationen und die Zustimmung des Nutzers. Ohne diesen Test wird kein echtes Anbieterkonto als verifiziert bezeichnet. Mobile Geräte verwenden den unten beschriebenen nativen Autorisierungsablauf; die tatsächliche Zustimmung bleibt unverifiziert.

Am 2026-09-09 geprüfte Referenzen:

Mobiler Client

Die Cloudschaltfläche öffnet den Verbindungsstatus sowie „Verbinden/Erneut verbinden“, „Jetzt synchronisieren“ und „Trennen“. Die Synchronisierung läuft ausschließlich im Vordergrund. AppAuth öffnet den Systembrowser, validiert den Zustand und generiert PKCE. Wenn die App wegen des Browsers in den Hintergrund wechselt, wird die Bibliothek gesperrt. Entsperren und autorisieren Sie sich nach der Rückkehr erneut lokal, bevor Rust den Code austauscht. Zugriffs- und Aktualisierungstokens werden von Rust geprüft/gespeichert und niemals an Dart zurückgegeben.

Erstellen Sie den Build mit Ihrer plattformspezifischen Registrierung eines öffentlichen Clients:

  • --dart-define=MEMORIES_ONEDRIVE_CLIENT_ID=...
  • --dart-define=MEMORIES_ONEDRIVE_REDIRECT_URI=app.memories.memories:/oauth/callback
  • --dart-define=MEMORIES_GOOGLE_CLIENT_ID=...
  • --dart-define=MEMORIES_GOOGLE_REDIRECT_URI=...

Nicht gesetzte Client-IDs deaktivieren die Anmeldung mit einer erklärenden Meldung. Betten Sie kein Webclient-Geheimnis ein und verwenden Sie die Loopback-Konfiguration des Desktopclients nicht erneut. Verwenden Sie die genaue native Umleitung, die der Anbieter für Ihre Plattform, Ihr Bundle/Paket und Ihre Signierungsidentität unterstützt. Google iOS-Registrierungen verwenden häufig das umgekehrte Client-ID-Schema; bei Google Android unterscheiden sich Registrierung und Umleitungsbeschränkungen und müssen vor der Verteilung eines Android-Builds anhand des vom Anbieter unterstützten nativen Ablaufs überprüft werden. Eine konfigurierte URI allein beweist nicht, dass die Zustimmung beim Anbieter unterstützt wird.

Das standardmäßig registrierte App-Schema ist app.memories.memories. Für ein anderes benutzerdefiniertes Schema akzeptiert Android die Gradle-Eigenschaft memoriesOAuthScheme (zum Beispiel über ORG_GRADLE_PROJECT_memoriesOAuthScheme); iOS verwendet MEMORIES_OAUTH_SCHEME in mobile/ios/Flutter/Memories.xcconfig. Das Schema muss mit der nativen Callbackregistrierung und der Dart-Umleitungs-URI übereinstimmen. Wenn Sie beide Anbieter aktivieren, registrieren Sie kompatible Callbacks oder fügen Sie das zweite Schema zum nativen Manifest/den URL-Typen hinzu. HTTPS-App-/Universal-Links benötigen die Zuordnungsdateien ihrer Plattform und eine native Konfiguration; der Standardbuild mit benutzerdefiniertem Schema aktiviert sie nicht.

Eine abgeschlossene Browseranmeldung kann eine alte Sitzung mit erhöhten Berechtigungen nicht wiederherstellen. Das Abbrechen der lokalen Passwortabfrage lässt die Cloudautorisierung unverändert. Sperren/Wechseln in den Hintergrund verhindert das Anwenden verspäteter Synchronisierungsergebnisse. Netzwerkfehler belassen Daten in der Warteschlange für ein späteres „Jetzt synchronisieren“; die Oberfläche unterscheidet einen abgeschlossenen Vorgang von einem begrenzten Durchlauf mit ausstehender Arbeit. Die Abmeldung entfernt lokale Tokens, nicht die Zustimmung beim Anbieter oder Clouddateien. Siehe Freigabekriterien für die Validierung mit echten Anbietern.