ObsiGate/docs/features/file-chat-169.md

Chat intégré par fichier — #169

• Statut : ✅ livré le 2026-10-08
• Effort : 3-4 j (réalisé en 1 session) | Impact : 🟢
• Transport : SSE existant (#62) — pas de second WebSocket

Ce qui a été livré

Backend

• Store backend/file_chat.py — historique JSON par paire (vault, path) sous data/chats/ :
  • nom de fichier = SHA-256 de vault\0path (32 premiers hex) : aucun séparateur de chemin utilisateur dans le nom → traversal impossible ;
  • plafond 500 messages par fichier (les plus vieux supprimés) ;
  • texte tronqué à 4000 caractères ;
  • écriture atomique (tmp + move) ; fichier corrompu → historique vide (fallback, pas de crash).
• Routes backend/routers/file_chat.py (tag OpenAPI « Files » dérivé) :
  • GET /api/file/{vault}/chat?path=… → historique chronologique ;
  • POST /api/file/{vault}/chat {path, text} → ajout + broadcast SSE ;
  • garde commune : require_auth + check_vault_access + resolve_safe_path (traversal → 403/500 via le handler ServiceError) ;
  • text ou path vides → 400 ; vault inconnu → 404.
• Schémas ChatMessageItem / ChatHistoryResponse / ChatMessageResponse dans backend/schemas.py (response_model sur les deux routes).
• Broadcast : sse_manager.broadcast("chat_message", {vault, path, message}).

Frontend

• frontend/js/filechat.js — panneau latéral :
  • bouton 💬 (.btn-chat) dans le groupe nav de la toolbar fichier (viewer.js), toggle ouvre/ferme ;
  • historique rendu chronologiquement, bulles « mine » à droite, textContent pour le corps (pas d'injection HTML) ;
  • envoi POST optimiste + dédoublonnage par id à la réception SSE ;
  • panneau fermé / autre fichier → toast « Nouveau message de … » (silencier si c'est son propre message).
• frontend/js/sync.js — listener SSE chat_message avec import dynamique de filechat.js (pas de cycle d'imports).
• CSS bloc #169 : panneau fixe 340 px, plein écran ≤ 768 px, variables CSS avec fallbacks, input 16 px (anti-zoom iOS).
• i18n : 10 clés chat.* dans fr.json et en.json.

Tests

• tests/test_file_chat.py — 15 tests : roundtrip store, isolation par fichier, plafond de rétention, troncature, traversal hashée, fichier corrompu, routes (200/400/404/403), fixture autouse isolant CHAT_DIR.
• tests/frontend/filechat.test.mjs — 6 tests JSDOM : empty state, rendu chronologique + classe mine, anti-injection HTML, append live + dédup par id, isolation inter-fichiers, toggle. Locales réellement chargées (fetch simulé vers frontend/locales/).
• Les deux sont ajoutés au pipeline CI (.gitea/workflows/ci.yml).

#190 — Suivi du document, chat général, ordre des onglets (2026-10-08)

A. Le panneau suit le document

• En-tête du panneau : .file-chat-target affiche le titre du document (l'attribut title porte le chemin complet).
• followFileChat(vault, path, title) est appelé en tête de renderFile() : panneau ouvert + autre document → re-cible (reload de l'historique) ; panneau fermé → no-op. Le bouton 💬 transmet data.title.

B. Chat général en onglet sidebar

• Onglet #sidebar-tab-chat (dernier, message-circle) + panneau #sidebar-panel-chat (liste + 📎 + saisie + Envoyer, Entrée = envoyer).
• Store : rien de nouveau — les sentinelles GLOBAL_VAULT="__global__" / GLOBAL_PATH="general" réutilisent add_message/get_messages.
• Routes : GET/POST /api/chat, POST /api/chat/upload, GET /api/chat/attachment/{name}.
• Pièces jointes : allow-list d'extensions (11 : images + vidéos), 25 MB, nom de stockage = UUID (le nom client n'est jamais utilisé), résolution par comparaison au nom + allow-list (aucun chemin utilisateur).
• Messages non lus : timestamp de dernière visite dans localStorage['obsigate-chat-unread'], comptage des messages plus récents d'un autre auteur, pastille rouge 99+ sur l'onglet, effacée à l'ouverture.
• URL : linkification http(s):// au rendu (texte autour en TextNode, donc pas d'injection).
• SSE : vault === "__global__" route vers la liste sidebar (append + clear) ou vers badge + toast selon que l'onglet est actif.

C. Ordre des onglets + filtre = recherche chat

• index.html : le bloc .sidebar-filter est déplacé après .sidebar-tabs.
• switchSidebarTab : placeholder sidebar.filter_chat, dispatch chat.
• initSidebarFilter (sidebar.js) : routeFilter/routeClear routent vers filterChatMessages() (texte et auteur, insensible à la casse).

#191 — Suppression, messages privés, boîte compacte, link preview (2026-10-08)

A. Suppression d'un post

• DELETE /api/chat/{id} et DELETE /api/chat/dm/{peer}/{id} : auteur du message ou admin (403 sinon), 404 si l'id n'existe pas.
• Store : delete_message(vault, path, id) — écriture atomique, False si absent ; broadcast SSE chat_deleted {vault, path, id}.
• Frontend : bouton 🗑 (.file-chat-del, visible au survol) rendu dans _messageEl uniquement si l'URL de suppression est fournie et que l'utilisateur est auteur/admin ; confirm() natif ; retrait local
  • retrait en direct chez tous via onChatDeleted (relais sync.js).

B. Messages privés 2 utilisateurs

• Store : DM_VAULT = "__dm__", dm_path(a, b) = paire triée → les deux participants lisent/écrivent le même document, indépendamment de l'ordre.
• Routes : GET /api/chat/users (destinataires — usernames + display_names, sans soi-même, aucun hash/mot de passe exposé), GET/POST /api/chat/dm/{username} (404 utilisateur inconnu, 400 DM à soi), DELETE /api/chat/dm/{username}/{id}.
• Frontend : rangée de pastilles .chat-channels (« Général » + un bouton par utilisateur) au-dessus du fil ; _channel état courant, _channelKey/_channelUrl/_channelDelUrl ; placeholder dédié chat.placeholder_dm ; non-lus par canal (compteurs dans localStorage, l'ancien mélange timestamp/compteur est devenu un compteur unique {"general": n, "dm:x": n}, remis à zéro à l'ouverture, pastille = total) ; les DM SSE routés par _pairOf(path).

C. Boîte d'édition compacte

• Bouton d'envoi réduit à une icône send (.file-chat-send-icon) dans les deux formulaires (panneau document + sidebar) ; la saisie garde toute la largeur. safeCreateIcons() à la fin du _renderShell.

D. Link preview

• build_preview(text) (store) : 1ʳᵉ URL du texte → garde SSRF _assert_public_http_url (host privé/loopback rejeté, schémas non http refusés) → httpx.get 5 s, 512 Ko, follow_redirects (limite httpx = 20) → parse OG par regex (og:title avec repli <title>, og:description, og:image, og:site_name) → {url, title, description, image, site}.
• Best-effort : n'importe quelle erreur (URL morte, timeout, garde) → None, le message passe quand même ; cache borné 200 entrées.
• Frontend : _previewEl rend une carte cliquable (vignette lazy no-referrer, site en capitales, titre/description tronqués 2 lignes) sous le corps du message.
• Schéma : ChatMessageItem.preview.

Tests #191

• pytest TestDelete (3), TestPrivateChat (8), TestLinkPreview (8, dont le happy path avec httpx.get mocké — un max_redirects inexistante sur httpx.get levait un TypeError silencieusement avalé par le try, testé par test_build_preview_happy_path_parses_og).
• JSDOM filechat.test.mjs +5 : carte preview, bouton supprimer (droit auteur/admin), onChatDeleted, compteurs non-lus, routage DM isolé du général (16 au total).

#192 — Saisie auto-agrandissante, accusé de réception, vignette de lien (2026-10-08)

A. Boîte de saisie qui grandit avec le texte

<input type="text"> → <textarea rows="1"> (panneau document créé dans _renderShell(), sidebar statique dans index.html). _autoGrow(el) pose height: auto puis min(scrollHeight, 160)px à chaque input, la règle CSS textarea.file-chat-input ajoute resize: none + overflow-y: auto (au-delà du plafond la zone défile) et la hauteur repasse à une ligne après l'envoi. Entrée (sans Maj) est interceptée dans les deux formulaires → envoi, Maj+Entrée garde le retour à la ligne. Le placeholder de la sidebar est aussi appliqué à l'init (t()), le HTML ne portant que le FR.

B. Accusé de réception (✓ envoyé / ✓✓ lu)

• Store (backend/file_chat.py) : le document de conversation gagne read = {username: dernier_ts} (get_read() / mark_read()), sous le _LOCK du read-modify-write partagé avec l'ajout et la suppression.
• API : les trois GET d'historique renvoient read (schéma ChatHistoryResponse.read) ; nouveau POST /api/chat/read (ChatReadResponse) avec _check_read() — général = tout membre, DM = pair uniquement (403 sinon), fichier = ACL vault + resolve_safe_path — qui marque la lecture et diffuse chat_read {vault, path, user, ts, read} en SSE.
• Client (filechat.js) : carte de lecture par surface (_fileRead, _channelRead). Un message est « lu » dès qu'un autre participant a un ts ≥ celui du message (ma propre lecture ne compte pas). _messageEl() affiche ✓/✓✓ (.file-chat-status, bleu accent quand lu) ; _applyRead() fait basculer les indicateurs affichés ; _syncRead() fusionne une carte reçue ; _markRead(vault, path) (POST fire-and-forget) est émis à l'ouverture d'une conversation et à la réception d'un message pendant qu'elle est affichée. onChatRead() (relais chat_read ajouté dans sync.js) actualise en direct et notifie l'expéditeur par toast chat.read_by quand un de ses messages passe à ✓✓ — jamais pour son propre écho.

C. BUG-109 — vignette des tuiles de lien

img-src 'self' data: blob: interdit toute og:image distante, et une og:image relative était résolue contre l'origine d'ObsiGate (404). _proxy_image(img_url, page_url) téléverse la vignette à l'envoi dans chat_uploads via save_attachment() (allow-list + nom UUID) et renvoie /api/chat/attachment/<uuid> — résolution urljoin contre la page, garde SSRF réutilisée, plafond PREVIEW_IMAGE_MAX (2 Mo), dérivation de l'extension depuis le content-type. Échec isolé → image = "", la carte reste (jamais de message perdu).

Tests #192

• pytest TestReadReceipts (7) : roundtrip store, messages préservés, POST /api/chat/read (enregistrement + restitution par le GET), 403 DM hors pair, 400 champs manquants, ACL vault, broadcast chat_read (spy sur sse_manager) ; TestLinkPreview +2 (proxy same-origin avec fichier écrit sur disque, dégradation sans vignette).
• JSDOM filechat.test.mjs +3 (19) : indicateur ✓/✓✓ (ma propre carte de lecture exclue, aucun indicateur sur les messages des autres), bascule en direct + notification + pas d'écho, textarea (tagName/rows, hauteur pilotée, Entrée intercepté / Maj+Entrée non).

#193 — Rendu markdown des posts (2026-10-09)

Un post du chat s'affiche désormais comme un document : titres, listes, tableaux, citations, blocs de code colorés — au lieu du texte brut avec liens cliquables.

A. Le rendu vient du serveur (pas de second moteur markdown)

• backend/file_chat.py::_decorate() ajoute un champ html à chaque message en réutilisant backend/render.py::_render_markdown() — le pipeline exact des documents : mistune (tableaux, strikethrough, notes, listes de tâches), résolution des wikilinks, normalisation des sauts de ligne, masquage des secrets (#188) et sanitizer BUG-021 en sortie. Aucun markdown côté client, donc aucun XSS nouveau à traiter : la sanitisation est déjà éprouvée.
• ChatMessageItem.html (schéma de réponse) : sans ce champ, response_model filtrait la clé.
• Le html est calculé à la lecture (get_messages()) et à l'ajout (_append()), donc il n'est jamais persisté dans data/chats/*.json : un message reste du texte, le rendu suit les évolutions du pipeline.
• L'écho SSE part avec le html : les autres clients voient le rendu sans attendre un refresh.
• Un échec de rendu n'emporte pas le message : repli silencieux (html = ""), le client affiche le texte brut.

B. Frontend : .md-content + highlight.js

• _fillBody() injecte le html dans un <div class="md-content"> (la typographie des documents) puis appelle safeHighlight() sur chaque pre code — le même helper (et les mêmes alias de langages) que le viewer. Mermaid n'est pas déclenché dans le chat.
• Repli intact : un message sans html (écho optimiste d'un autre client) repasse par l'ancien chemin texte + URL cliquable.
• CSS : .file-chat-body.file-chat-md annule le white-space: pre-wrap hérité de la bulle (sinon les retours à la ligne du HTML source créaient des lignes vides) et compacte .md-content (tailles, marges, pre/table en overflow-x: auto) pour tenir dans une bulle de 92 % de large.

Tests #193

• pytest TestMarkdownRendering (7) : html présent à l'ajout et à la lecture, html absent du JSON stocké, classe language-xxx conservée (ce sur quoi hljs se branche), tableaux/listes, <script> neutralisé, routes POST/GET (chat de fichier + chat général) et écho SSE porteur du html. Suite : 1689 passed.
• JSDOM filechat.test.mjs +2 (27) : post avec html → .md-content, <strong>, pre code.language-python ; post sans html → texte brut et URL cliquable conservés.

Décisions

• SSE plutôt qu'un second WebSocket : le transport de #62 (EventSource /api/events, auth par cookie) existe déjà côté client dans sync.js ; un WS par fichier aurait dupliqué reconnexion/heartbeat/auth pour zéro bénéfice sur du messages-postés.
• Pas d'événement dans le panneau de sync (_addEvent) : les messages de chat gonfleraient l'historique d'événements d'index sans valeur.
• Tag OpenAPI : pas de tag maison (file-chat) — non déclaré dans TAGS_METADATA, ce qui cassait test_used_tags_are_declared. Les routes /api/file/* sont dérivées automatiquement sous « Files ».