Lesebibliothek
Eine Suchverlaufskarte ohne gespeicherte Geheimnisse aufbauen
Führen Sie einen nützlichen Quantisierungssuchverlauf und trennen Sie dabei Zugangsdaten, abgesendete Bedingungen, Antwortbeobachtungen und persönliche Deutungsnotizen.
Wiederverwendbare öffentliche Eingaben auflisten
Die Verlaufskarte sollte den Filtervertrag der API genau abbilden. Erfassen Sie im vorgeschlagenen LocalLLaMA-Protokoll q, subreddit, author, kind, from, to, min_score, limit und page, soweit sie verwendet wurden. Ein kompaktes Beispiel lautet q=quantization, subreddit=LocalLLaMA, limit=3, page=1. Speichern Sie Daten als tatsächlich übermittelte UTC-Werte im Format YYYY-MM-DD. Diese Angaben erläutern Anfragebedingungen; sie beweisen keinen bestimmten gelieferten Beitrag, und eine Wiederholung garantiert später nicht dieselbe Antwort.
Verstehen Sie öffentliche Eingaben als Felder ohne Zugangsdaten, nicht als automatisch harmlose Informationen. Eine Anfrage kann einen vertraulichen Projektnamen enthalten, eine Notiz eine unbeabsichtigt offengelegte Identität. Entscheiden Sie, was gespeichert oder exportiert werden soll, statt das gesamte Anfrageobjekt zu kopieren. Authentifizierungsheader gehören nicht in den Verlauf. Speichert die Anwendung eine Antwort lokal, kennzeichnen Sie sie getrennt von der Anfrage und halten Sie den Abrufzeitpunkt fest. Sonst kann ein Link zur Wiederholung mit einer archivierten Kopie des ursprünglichen Ergebnisses verwechselt werden.
Geheimnisspeicherung getrennt halten
Das Backend des Aufrufers braucht Zugriff auf seinen gespeicherten API-Schlüssel, um X-API-Key oder Authorization: Bearer zu senden. Ein Einweg-Hash allein liefert dieses ausgehende Zugangsmittel nicht. Bewahren Sie den nutzbaren Schlüssel in geeignetem geheimen Backend-Speicher auf, außerhalb von Browser-Bundles, Query-Strings, Verlaufsexporten und Diagnoseprotokollen. Der Dienst selbst speichert Schlüsselhash und Präfix zur Authentifizierung; das ist eine andere Aufgabe. Vollständige Schlüssel werden nur einmal bei Registrierung oder Regeneration angezeigt, und eine Regeneration macht den alten sofort ungültig. Ein Verlaufseintrag darf nicht versehentlich zur Schlüsselsicherung werden.
Trennen Sie drei Beziehungen: das Anwendungskonto des Lesers, die Sitzung des Dienstbetreibers und den API-Schlüssel für Abrufe. Dienstschlüssel und Guthaben gehören zum jeweiligen Mandanten; ein anderer Host macht einen fremden Mandantenschlüssel nicht gültig. Zugangsdaten aus dem Verlauf herauszuhalten verringert einen Offenlegungsweg, schützt gespeicherte Anfragen und Notizen aber nicht vor jedem Browser- oder Berechtigungsproblem. Prüfen Sie die Speicher- und Freigabeentscheidungen der Anwendung. Bewerben Sie diese vorgeschlagene Karte weder als geprüfte Sicherheitsgrenze noch als Verlaufsfunktion der Archiv-API.
Deutungsnotizen speichern
Trennen Sie Beobachtungen und Schlussfolgerungen. Eine Karte könnte festhalten, dass drei Datensätze angezeigt wurden, einer keinen nutzbaren Text hatte und die Bedingungen des Speicherexperiments weiterhin fehlen. Das ist eine beispielhafte Anmerkung, kein beobachtetes Archivergebnis. Wenn Sie pagination.total speichern, bewahren Sie auch pagination.relation sowie die zur Erklärung nötigen Fortsetzungs- und Fensterindikatoren auf. Eine Untergrenze ist keine exakte Anzahl. Keines dieser Felder misst Relevanz oder die Häufigkeit des zugrunde liegenden Problems.
Lassen Sie Leser kurz erklären, weshalb sie einen Verweis behalten. Kennzeichnen Sie dies als eigene Notiz, erhalten Sie verfügbare Quellenkennungen und vermischen Sie sie nicht mit zitiertem Quellmaterial. Optionale Felder können fehlen, und Elternverweise liefern keine vollständige Diskussion. Das Öffnen einer gespeicherten Antwort muss keinen API-Aufruf auslösen; eine ausdrückliche Aktualisierung ist dagegen ein neuer Abruf. Erfolgreiche Aktualisierungen kosten einen Credit, auch ohne Treffer. Bewahren Sie eine fehlgeschlagene oder ungewisse Aktualisierung als eigenes Ergebnis auf, statt die frühere Beobachtung durch eine unbeschriftete leere Karte zu ersetzen.
Aufbewahrungsgrenzen prüfen
Definieren Sie Löschung, Export und Ablauf in Ihrer Anwendung, bevor Sie die Karte als dauerhaften Verlauf anbieten. Eine lokale Karte zu entfernen löscht die von Ihrer Implementierung gespeicherten Daten; es löscht weder einen Archivdatensatz noch schließt es das Dienstkonto oder verändert dessen Zahlungsdaten. Browserbereinigung, Geräteverlust oder Speicherbeschränkungen können lokale Verläufe entfernen. Bieten Sie Synchronisation oder Sicherungen an, beschreiben und prüfen Sie diese als eigene Anwendungsfunktionen. Beides ist kein Archivendpunkt, und der Artikel belegt nicht, dass es bereits implementiert wurde.
Hier ist keine feste Aufbewahrungsdauer für Kontodaten angegeben; das verspricht keinen dauerhaften Zugriff auf Archivinhalt. Eine aufbewahrte Anfrage kann verständlich bleiben, wenn die Quelle später verschwindet, sofern die Karte frühere Beobachtung und neuen Abruf trennt. Prüfen Sie Exporte auf Geheimnisse und sensible Notizen und lassen Sie den Leser entscheiden, was bleibt. Das nützliche Ergebnis ist die nachvollziehbare Dokumentation einer Suchentscheidung, keine Versicherung, dass Daten, Deutung oder Quellenlink unbegrenzt gültig bleiben.
