update doc about internal requests

doc/internal_requests.md

@@ -12,15 +12,15 @@ de commande ou lors d'un processus asynchrone exécuté par messenger.
 Pour éviter tout risque de sécurité lié à ces routes :
 
 * on restreint leur accès aux ips internes
-* on conditionne l'autorisation à la présence d'un token ou à une authentification en tant que super-admin.
+* on conditionne l'autorisation soit à la présence d'un token, soit à une authentification en tant que super-admin.
 * on limite les routes concernées
 
-Ainsi, si l'on prend l'exemple d'une requête `/internal/download/123` sur ap2i :
+Ainsi, si l'on prend l'exemple d'une requête `/internal/download/123` envoyée à ap2i :
 
-* Un utilisateur dans le VPN sans le token qui ferait un curl à cette adresse recevra une erreur 403
+* Un utilisateur dans le VPN sans le token qui ferait un CURL à cette adresse recevra une erreur 403
 * Un utilisateur hors VPN, même s'il connaissait le token, recevra une erreur 403, car n'ayant pas une ip autorisée
 * Une requête issue de la V1 avec le bon token et provenant d'une ip interne sera autorisée sans authentification
-
+* Une requête d'un utilisateur connecté en tant que super admin et à l'intérieur du VPN pourra aussi aboutir.
 ### Ip internes 
 
 Les ips considérées comme interne sont :
@@ -36,13 +36,14 @@ Les ips considérées comme interne sont :
 
 ### Mise en oeuvre
 
-On met en place un pattern de routes de la forme `/api/internal/*` qui sera uniquement dédié aux requêtes internes entre
-les deux API ou à d'autres éventuels échanges entre systèmes.
+On met en place un pattern de routes de la forme `/api/internal/*` qui sera uniquement dédié aux requêtes internes 
+entre les services opentalent.
 
 Les appels à cette route ne sont autorisés que si :
 
 1. Que l'ip du client dont émet la requête fait partie d'un pool autorisé d'ips internes
-2. Qu'un header 'internal-requests-token' est défini et que sa valeur correspond à la valeur attendue.
+2. Qu'un header 'internal-requests-token' est défini et que sa valeur correspond à la valeur attendue OU que 
+   l'utilisateur est connecté en tant que super-admin.
 
 Si ces deux conditions ne sont pas remplies, la requête est rejetée, et ce même si l'utilisateur est authentifié.
 
@@ -52,13 +53,13 @@ Les routes internal sont configurées ici : `config/packages/security.yaml`
 
 ### Valider le fonctionnement
 
-Soit `$id` l'id d'un fichier stocké sur l'environnement V2
+Exemple avec la route dédié au téléchargement des fichiers, `$id` étant l'id d'un fichier stocké sur l'environnement V2.
 On part du principe que l'utilisateur authentifié a des droits suffisants pour voir ce fichier.
 
 
 Côté ap2i, les requêtes suivantes doivent donner les résultats correspondants :
 
-| query                      | header défini | authentifié | VPN activé | Résultat attendu |
+| query                      | header défini | super-admin | VPN activé | Résultat attendu |
 |----------------------------|---------------|-------------|------------|------------------|
 | /api/internal/download/$id | NON           | NON         | NON        | 401 Unauthorized |
 | /api/internal/download/$id | OUI           | NON         | NON        | 401 Unauthorized |