1.4 KiB
title
| title |
|---|
| Rate limiting sur les endpoints IA |
La clé API publique est lisible dans le navigateur dès que visitapp-web est en ligne, et rien n'empêchait d'y boucler jusqu'à vider le quota de jetons d'un client. AddRateLimiter natif .NET 8, partition par instance — c'est l'instance qui porte le quota protégé, l'abus chez l'un ne doit pas ralentir les autres — fenêtre fixe 120 req/min, 429 avec Retry-After. Appliqué à chat et translate : les deux consomment des jetons, et translate est atteignable avec la même clé. Ordre du pipeline choisi, pas subi : après UseCors (un 429 posé avant les en-têtes CORS s'affiche comme une erreur CORS et le client ne voit jamais le vrai code) et après UseAuthentication (sinon la partition n'a pas le claim d'instance et tout le monde tombe dans le même seau). dotnet build ✅, dotnet test 203/203. ⚠️ Jamais exercé à l'exécution : le projet n'a aucune infrastructure de test HTTP (pas de WebApplicationFactory), et en monter une pour ce seul contrôle serait disproportionné. Vérification manuelle à faire une fois : une boucle de 130 appels sur /api/AI/chat doit basculer en 429 vers le 121e.