Couvrir l'API postes par des tests (auth, allowlist, payload, fraicheur) #14

New issue

Closed

opened 2026-08-15 20:10:16 +00:00 by maximus · 0 comments

maximus commented

2026-08-15 20:10:16 +00:00

Owner

Suite de tests dediee au nouveau chemin, sur le patron de findings.test.js (serveur http reel + repertoire temporaire). La couverture securite est le coeur de l'issue : c'est la premiere surface d'ecriture publique du service.

Fichiers concernes

__tests__/hosts.test.js (creer)
__tests__/findings.test.js (patron)

Depends on

Criteres d'acceptation

Auth : sans token 401 ; token de LECTURE refuse sur le POST ; token d'INGESTION refuse sur les routes de lecture ; HOSTS_INGEST_TOKEN absent 503
Identifiants : inconnu mais bien forme 403 ; ../../etc/passwd, ..%2f..%2fetc et THINKPAD renvoient 404 — ne PAS « corriger » ces cas en elargissant la regex de route
Payload : JSON illisible 400 ; champ manquant 400 ; corps de 8 Kio 413
Une cle __proto__ et un hostname de 4 Kio sont absents du fichier ecrit
Fraicheur : online teste de part et d'autre du seuil (899 / 900 / 901 s) ; ageSeconds coherent ; neverSeen pour un id allowliste sans fichier
Aller-retour POST puis GET ; fichier corrompu a la main degrade l'entree sans faire tomber la reponse
npm test : les 14 tests de findings.test.js et les tests d'auth de #12 passent sans modification

Review caveats

TECHNIQUE (CRITIQUE) : les attentes 403 sur les identifiants malformes seraient FAUSSES — c'est 404. Un test rouge ici doit se corriger dans le test, jamais en assouplissant la regex de route.

Decisions prises en planification

Tests separes de l'implementation pour que la surface de securite soit revue pour elle-meme.

Spec source

la-compagnie-maximus/spec-plan-monitoring-postes.md + spec-decisions-monitoring-postes.md (depot different : ce body est auto-suffisant, ne pas compter sur le fichier) (Issue 4)

Suite de tests dediee au nouveau chemin, sur le patron de `findings.test.js` (serveur http reel + repertoire temporaire). La couverture securite est le coeur de l'issue : c'est la premiere surface d'ecriture publique du service. ## Fichiers concernes - `__tests__/hosts.test.js` (creer) - `__tests__/findings.test.js` (patron) ## Depends on - #13 ## Criteres d'acceptation - [ ] Auth : sans token 401 ; token de LECTURE refuse sur le POST ; token d'INGESTION refuse sur les routes de lecture ; `HOSTS_INGEST_TOKEN` absent 503 - [ ] Identifiants : inconnu mais bien forme 403 ; `../../etc/passwd`, `..%2f..%2fetc` et `THINKPAD` renvoient 404 — ne PAS « corriger » ces cas en elargissant la regex de route - [ ] Payload : JSON illisible 400 ; champ manquant 400 ; corps de 8 Kio 413 - [ ] Une cle `__proto__` et un `hostname` de 4 Kio sont absents du fichier ecrit - [ ] Fraicheur : `online` teste de part et d'autre du seuil (899 / 900 / 901 s) ; `ageSeconds` coherent ; `neverSeen` pour un id allowliste sans fichier - [ ] Aller-retour POST puis GET ; fichier corrompu a la main degrade l'entree sans faire tomber la reponse - [ ] `npm test` : les 14 tests de `findings.test.js` et les tests d'auth de #12 passent sans modification ## Review caveats - TECHNIQUE (CRITIQUE) : les attentes 403 sur les identifiants malformes seraient FAUSSES — c'est 404. Un test rouge ici doit se corriger dans le test, jamais en assouplissant la regex de route. ## Decisions prises en planification - Tests separes de l'implementation pour que la surface de securite soit revue pour elle-meme. ## Spec source la-compagnie-maximus/spec-plan-monitoring-postes.md + spec-decisions-monitoring-postes.md (depot different : ce body est auto-suffisant, ne pas compter sur le fichier) (Issue 4)