batchCooking/services/tech-step-intent-service/intent_service/security.py
Nicolas 18abae7b6a feat(recipes): migre la detection des tech steps de node-nlp vers un microservice Python spaCy
Remplace TechStepClassifierService's node-nlp (NlpManager) par
services/tech-step-intent-service, un microservice FastAPI/spaCy dedie
(PhraseMatcher pour le NER par synonymes, textcat pour la classification
d'intention). Corpus (TECH_STEP_TRAINING_DATA) toujours possede par
apps/api, pousse au service via POST /v1/train a chaque warm-up ; le
service ne touche jamais Postgres (meme posture que
services/tech-step-llm-worker).

Cote apps/api :
- intent-service-client.ts : client HTTP vers le nouveau service
- tech-step-matcher.ts : delegue NER + intent classification au client,
  logique pure (splitIntoClauses, seuil/fallback) inchangee
- env.ts : INTENT_SERVICE_BASE_URL/INTENT_SERVICE_SECRET (secret requis,
  service coeur non optionnel)
- server.ts : warm-up avec retry/backoff (service Python demarre a part)
- scripts/calibrate-tech-step-threshold.ts : recalibration empirique de
  CONFIDENCE_THRESHOLD contre le jeu d'eval existant
- node-nlp retire (package.json, node-nlp.d.ts, model.nlp du .gitignore)

docker-compose.yml : nouveau service tech-step-intent-service (pas de
port expose, healthcheck, app en depend). CI : job intent-service-test
(pytest) + le job test demarre le service en arriere-plan avant la suite
Mocha (jamais de mock d'un service interne, cf specs/dev-conventions.md).

Verifie : 26/26 tests pytest du service (dont les offsets caracteres
exacts de tech-step-matcher.test.ts), lint + build complets du monorepo,
smoke test HTTP reel bout en bout. La suite Mocha et docker compose
build/up n'ont pas pu etre executes dans cet environnement (pas de
Postgres/Docker disponibles ici) — a confirmer via la CI et en local.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-25 20:11:30 +02:00

35 lines
1.4 KiB
Python

"""Authentification des appels entrants — miroir inversé de `requireInternalWorker`
(`apps/api/src/middlewares/require-internal-worker.ts`) : ici c'est
`apps/api` qui appelle *ce* service, donc c'est ce service qui vérifie le
secret plutôt que de l'envoyer.
Comparaison à temps constant (`hmac.compare_digest`, l'équivalent Python du
`timingSafeEqual` de Node utilisé côté `apps/api`) — même raisonnement :
un attaquant ne doit rien apprendre de la durée de la comparaison au-delà de
ce qu'une différence de longueur révèle déjà.
"""
import hmac
from fastapi import Header, HTTPException, status
from .config import settings
_SECRET_HEADER_NAME = "x-intent-service-secret"
def require_valid_secret(
x_intent_service_secret: str | None = Header(default=None, alias=_SECRET_HEADER_NAME),
) -> None:
"""Dépendance FastAPI montée sur chaque route protégée (`/v1/*`) — pas
`GET /health`, sondé par le healthcheck Docker sans configuration
d'auth propre.
`settings.intent_service_secret` est garanti non vide par `config.py`
(pas de valeur par défaut dans `Settings`) — le seul cas à traiter ici
est un header manquant ou incorrect côté appelant.
"""
if x_intent_service_secret is None or not hmac.compare_digest(
x_intent_service_secret, settings.intent_service_secret
):
raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Not authenticated")