Bibliothèque de lecture
Créez une fiche d'historique de recherche sans y stocker de secrets
Conservez un historique utile des recherches de quantification en séparant identifiants secrets, conditions envoyées, observations sur les réponses et notes du lecteur.
Énumérez les paramètres non secrets réutilisables
La structure de la fiche d'historique doit suivre exactement le contrat des filtres de l'API. Pour le carnet LocalLLaMA proposé, enregistrez les valeurs envoyées de q, subreddit, author, kind, from, to, min_score, limit et page lorsque ces paramètres sont utilisés. Exemple concis : q=quantization, subreddit=LocalLLaMA, limit=3, page=1. Conservez les dates UTC réellement envoyées au format YYYY-MM-DD. Ces entrées expliquent les conditions de la requête ; elles ne prouvent pas qu'une discussion précise a été renvoyée, et les réutiliser ne garantit pas la même réponse plus tard.
Considérez ces paramètres publics comme des champs qui ne servent pas à l'authentification, pas comme des informations forcément anodines. Une recherche peut contenir le nom d'un projet privé et une note identifier une personne que le lecteur ne souhaitait pas divulguer. Choisissez ce qui doit être stocké ou exporté au lieu de copier l'objet de requête entier. Excluez les en-têtes d'authentification de l'historique. Si l'application conserve une réponse localement, identifiez-la séparément de la requête et datez sa récupération. Sinon, un lien permettant de relancer la recherche risque d'être pris pour une copie archivée du résultat original.
Séparez le stockage des secrets
Le backend de l'appelant doit disposer de sa clé API enregistrée pour envoyer X-API-Key ou Authorization: Bearer. Un hachage à sens unique ne suffit pas à fournir cet identifiant secret sortant. Gardez la clé utilisable dans un stockage de secrets adapté au backend, hors des fichiers distribués au navigateur, chaînes de requête, exports d'historique et journaux de diagnostic. Le service lui-même conserve un hachage et un préfixe de clé pour l'authentification : c'est un rôle différent. Les clés complètes ne s'affichent qu'une fois, à l'inscription ou à la régénération ; régénérer invalide immédiatement l'ancienne clé. Une fiche d'historique ne doit jamais devenir une sauvegarde accidentelle de clé.
Distinguez trois relations : le compte du lecteur dans votre application, la session de l'opérateur auprès du service et la clé API du service utilisée pour récupérer les données. Les clés et soldes du service sont propres à chaque tenant ; changer d'hôte ne rend pas valide la clé d'un autre tenant. Exclure les identifiants secrets de l'historique réduit une voie d'exposition, sans protéger les recherches ou notes stockées contre tout problème de navigateur ou de contrôle d'accès. Examinez les choix de stockage et de partage de votre application. Ne présentez pas cette fiche proposée comme une protection de sécurité testée ni comme une fonction d'historique fournie par l'API de l'archive.
Conservez des notes d'interprétation
Séparez observations et conclusions. Une fiche pourrait indiquer que la requête a renvoyé trois enregistrements affichés, que l'un ne comportait pas de corps de texte exploitable et que le lecteur recherche encore les conditions de mémoire de l'expérience. Cette annotation est illustrative, pas un résultat observé dans l'archive. Si vous conservez pagination.total, gardez aussi pagination.relation, ainsi que les indicateurs de continuation et de fenêtre nécessaires pour expliquer la réponse. Une borne inférieure n'est pas un décompte exact. Aucun de ces champs ne mesure la pertinence d'un enregistrement ni la fréquence du problème sous-jacent.
Permettez au lecteur d'expliquer brièvement pourquoi il conserve une référence. Présentez ce texte comme sa note, gardez l'identité de source disponible et évitez de le mêler aux citations. Des champs source facultatifs peuvent manquer ; les références aux parents ne fournissent pas une discussion complète. Rouvrir une réponse déjà enregistrée ne nécessite pas forcément d'appel API, tandis qu'une actualisation explicite est une nouvelle récupération. Les actualisations réussies coûtent un crédit, même vides. Conservez l'échec ou l'incertitude d'une actualisation comme une issue distincte au lieu de remplacer l'ancienne observation par une fiche blanche sans explication.
Examinez les limites de conservation
Définissez la suppression, l'export et l'expiration propres à cette application avant de proposer la fiche comme un historique durable. Supprimer une fiche locale retire les données que votre implémentation a choisi de conserver ; cela ne supprime pas un enregistrement de l'archive, ne ferme pas le compte du service et ne modifie pas ses écritures de paiement. L'effacement du navigateur, la perte d'un appareil ou des restrictions de stockage peuvent faire disparaître l'historique local. Si vous proposez synchronisation ou sauvegardes, décrivez-les et testez-les comme des fonctions distinctes de l'application. Ce ne sont pas des endpoints de l'archive, et cet article n'établit pas qu'elles sont implémentées.
Le service n'indique ici aucune durée fixe de conservation des données du compte ; cela ne promet pas un accès permanent au contenu archivé. Une requête conservée peut rester compréhensible même si une source devient indisponible, à condition que la fiche distingue l'ancienne observation d'une nouvelle récupération. Examinez les exports pour y repérer secrets et notes sensibles, puis laissez le lecteur choisir ce qu'il garde. Le produit utile est une trace compréhensible d'une décision de recherche, pas l'assurance que ses données, son interprétation ou son lien source resteront valides indéfiniment.
