Une politique sur les arguments d'un appel, pas seulement sur l'outil

Jusqu'ici un appel d'outil était jugé sur quatre éléments : qui appelle, quel serveur, quel outil, et si l'appel lit ou écrit. Les arguments restaient hors champ, or c'est là que se joue l'ampleur des dégâts. Le droit d'appeler un outil de suppression n'est pas le droit de l'appeler sur le projet de production.

Les règles d'arguments comblent ce manque. Une règle s'applique aux valeurs que porte réellement l'appel et tranche cet appel-là, pas l'octroi qui se trouve derrière. C'est la moitié de la décision que toutes les passerelles comparables avaient et que nous n'avions pas.

Elles sont évaluées dans le processus de la passerelle plutôt que par un appel au backend, et c'est un choix délibéré, pas un raccourci. Une règle d'argument tranche un appel unique : elle ne peut donc pas partager la clé de cache d'une décision d'octroi, et la faire passer par HTTP ajouterait un aller-retour backend devant chaque appel d'outil, liant la disponibilité de la passerelle à celle du backend. Les règles sont lues par serveur et mises en cache quelques secondes, si bien qu'un changement prend effet dans cette fenêtre, le même plafond que celui qui s'applique déjà à la mise en pause d'un serveur.