docs(mail-browser): phase 2 attachments+draft-reply deployes et testes (2026-07-23), skill hermes-tt cable sur API

This commit is contained in:
2026-07-23 06:50:35 +00:00
parent c7053bc5d6
commit 7254dcea63
+52 -60
View File
@@ -1,73 +1,65 @@
# Acces boite mail O365 pro (hermes-tt) — historique et decision # MAIL-BROWSER-HERMES-TT
## Echec V0 : hermes-mail-proxy (Graph API device code flow) Runbook du service de lecture/reponse mail O365 pour hermes-tt, via un
Tentative : client public officiel Microsoft ("Microsoft Graph Command Line Tools", navigateur Edge deja authentifie tournant dans le conteneur
client_id 14d82eec-204b-4c2f-b7e8-296a70dab67e) via MSAL device code flow, pour `hermes-mail-browser` (session MFA maintenue cote serveur).
contourner le besoin d'enregistrement d'appli Azure AD (bloque en self-service sur
le tenant TT). Code deploye port 3060 (hermes-mail-proxy), jamais authentifie :
consentement Mail.Read/Mail.ReadWrite/Mail.Send bloque par l'admin meme sur ce
client pre-consenti. Confirme le 22/07/2026 (curl /auth/status -> authenticated:false
apres plusieurs semaines up). Container arrete et supprime le 22/07/2026, port 3060
libere. Ne pas retenter la voie Graph API sur ce tenant sans intervention admin TT.
## Decision V1 : hermes-mail-browser (session navigateur persistante) ## Architecture
Principe : authentification 100% humaine (Nabil, MFA inclus) via noVNC sur un
navigateur reel tournant sur le NAS (IP maison tunisienne). L'automatisation ne
fait QUE lire sur la session deja ouverte — jamais de re-authentification
automatisee, jamais de credentials stockes en clair.
Stack : - Conteneur : `hermes-mail-browser` (reseau Docker `n8n`)
- Microsoft Edge reel (channel msedge, pas Chromium generique) — fingerprint - API interne : `http://hermes-mail-browser:8000` (joignable par
Sec-CH-UA coherent avec un poste Windows corporate, reduction des heuristiques `hermes-agent-tt` sur le meme reseau, pas besoin du port 3110 expose)
de detection cote Defender for Cloud Apps. - noVNC : port 8810 (LAN uniquement) — pour reconnexion manuelle O365/MFA
- Affichage virtuel Xvfb + x11vnc, expose uniquement en LAN via noVNC (port 8810, - Envoi des projets de reponse : SMTP ik.me vers la boite pro de Nabil
bind 192.168.100.33, AUCUN vhost DSM, AUCUN reverse-proxy). (nabil.derouiche@tunisietelecom.tn)
- Edge lance en persistant (--user-data-dir sur volume monte, profil survit aux
redemarrages) avec remote debugging port 9222 (localhost uniquement).
- API FastAPI (port 3110) se connecte au MEME navigateur via CDP
(connect_over_cdp) — pas d'instance separee — pour lire la boite de reception.
hermes-tt consomme cette API en lecture seule.
Scope Phase 1 (lecture seule) : liste boite de reception (expediteur, objet, date, ## Statut — Phase 2 : COMPLETE (deployee et testee avec succes)
lu/non lu, apercu), lecture corps complet d'un mail. Aucune action d'ecriture
(envoi, suppression, deplacement) en V1.
Gestion expiration session : l'API detecte l'atterrissage sur Endpoints construits, deployes et testes le 2026-07-23 :
login.microsoftonline.com et renvoie 409 "reauthentification manuelle requise"
plutot que de tenter quoi que ce soit — Nabil rouvre noVNC, se reauthentifie,
la session persiste a nouveau.
Ports : 3110 (API interne), 8810 (noVNC, LAN uniquement). Conteneur : - `GET /health` — conteneur sain, `authenticated: true`
hermes-mail-browser, reseau n8n, UID/GID 1026:100, volume data/ pour le profil - `GET /inbox?limit=N` — liste (expediteur / objet / heure / apercu) ;
navigateur. `aria_label` contient "pieces jointes" si le mail en a
- `GET /message/{index}` — corps texte complet du mail
- `GET /message/{index}/attachments` — teste : liste des PJ, OK
- `GET /message/{index}/attachments/{filename}/text` — teste sur .docx ET
.pdf, extraction correcte confirmee (extraction auto PDF/DOCX/XLSX)
- `POST /draft-reply` `{"subject":"...","body_text":"..."}` — teste : mail
reellement recu dans la boite O365 pro. Envoie un PROJET vers la boite de
Nabil (jamais vers le correspondant). Prefixe de sujet
`[REPONSE PROPOSEE] Re: <objet>` ajoute automatiquement par l'API.
- Reseau : `hermes-agent-tt` joint `http://hermes-mail-browser:8000/health`
sans probleme (meme reseau Docker `n8n`) — teste, OK.
Statut : conteneur deploye et sain, en attente authentification manuelle (22/07/2026). ## Skill hermes-tt
## Mise a jour 22/07/2026 soir — validation phase 1 complete `/opt/data/skills/mail-o365-tt.md` (dans `hermes-agent-tt`) reecrit le
2026-07-23 : les anciennes sections "ENVOI MAIL — SMTP Infomaniak" et
"LECTURE MAIL — OWA Navigateur" (methode `browser_snapshot`, obsolete car
bloquee par le MFA) ont ete entierement remplacees par des instructions
pointant vers l'API ci-dessus. Regle centrale conservee : hermes-tt ne
repond JAMAIS directement a un correspondant, il envoie toujours un projet a
Nabil qui decide et envoie lui-meme depuis OWA. Les Cas d'usage 1
(Trouver+envoyer), 3 (Ingestion AO), 4 (Veille reglementaire) et le bloc
REGLES COMPORTEMENTALES ont ete conserves, adaptes a la nouvelle API.
Bug corrige pendant la validation : premiere version de main.py ouvrait une ## Session expiree (code 409)
nouvelle connexion Playwright a CHAQUE requete. Deux requetes de test annulees
cote client (timeout curl) ont laisse des coroutines bloquees cote serveur,
qui ont ensuite bloque toute nouvelle tentative (verrou de spawn du driver
Playwright). Corrige : connexion unique partagee, ouverte au demarrage de
app (FastAPI lifespan), reutilisee pour toutes les requetes, timeout de
securite 15s sur la connexion CDP.
Piege reseau rencontre en testant : ports 3110/8810 bindes UNIQUEMENT sur Si l'API renvoie **409**, la session du navigateur a expire. NE JAMAIS
192.168.100.33 (delibere, pas de bind 0.0.0.0). Injoignable depuis un tenter de re-authentifier depuis l'agent : signaler a Nabil qu'une
conteneur Docker (mcp-nas) via 172.17.0.1 ou directement via 192.168.100.33 reconnexion manuelle via noVNC (port 8810, LAN) est necessaire.
depuis un container — passer par ssh nas-host pour tout test/usage agent.
Tests reussis en conditions reelles (session Nabil authentifiee) : ## PIEGE — recreate / docker compose up -d du conteneur
- GET /auth/status -> authenticated:true
- GET /inbox?limit=5 -> expediteur/objet/heure/apercu corrects (5/5), y compris
un mail metier Zone Sud reel
- GET /message/0 -> corps complet correctement extrait
Phase 1 (lecture seule boite de reception) fonctionnelle, prete pour usage Edge tue brutalement laisse des verrous perimes dans le volume persistant.
par hermes-tt. AVANT tout `docker compose up -d` / recreate de `hermes-mail-browser`,
TOUJOURS supprimer d'abord :
Reste a faire : calibrer le 409 sur expiration reelle de session (pas encore ```
observe) ; evaluer robustesse des selecteurs OWA dans la duree ; envisager rm -f /volume1/docker/hermes-mail-browser/data/profile/SingletonLock \
V1.5 (appel API interne OWA via page.evaluate+fetch) si le DOM scraping /volume1/docker/hermes-mail-browser/data/profile/SingletonCookie \
devient trop lent. /volume1/docker/hermes-mail-browser/data/profile/SingletonSocket
```
Incident deja rencontre et resolu deux fois — cause = verrous Singleton
perimes empechant Edge de redemarrer dans le profil persistant.