5 lines
1.4 KiB
Markdown
5 lines
1.4 KiB
Markdown
---
|
|
title: Rate limiting sur les endpoints IA
|
|
---
|
|
<span>La clé API publique est <strong>lisible dans le navigateur</strong> 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. <code>AddRateLimiter</code> natif .NET 8, <strong>partition par instance</strong> — 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 <code>Retry-After</code>. Appliqué à <code>chat</code> <strong>et <code>translate</code></strong> : les deux consomment des jetons, et <code>translate</code> est atteignable avec la même clé. Ordre du pipeline choisi, pas subi : <strong>après <code>UseCors</code></strong> (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 <strong>après <code>UseAuthentication</code></strong> (sinon la partition n'a pas le claim d'instance et tout le monde tombe dans le même seau). <code>dotnet build</code> ✅, <code>dotnet test</code> <strong>203/203</strong>. ⚠️ <strong>Jamais exercé à l'exécution</strong> : le projet n'a aucune infrastructure de test HTTP (pas de <code>WebApplicationFactory</code>), et en monter une pour ce seul contrôle serait disproportionné. Vérification manuelle à faire une fois : une boucle de 130 appels sur <code>/api/AI/chat</code> doit basculer en 429 vers le 121<sup>e</sup>.</span>
|