# Internal Requests

### Principe général

Les requêtes internes sont des requêtes échangées entre les services internes à l'entreprise (maestro, ap2i, 
opentalent-platform...), par exemple pour demander un fichier.

Ces requêtes ne sont pas systématiquement protégées par l'authentification Symfony standard, car elles doivent 
pouvoir être exécutées en dehors du cadre d'une requête utilisateur, par exemple lors d'une exécution en ligne 
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 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` envoyée à ap2i :

* 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 :

- Le localhost (`127.0.0.[0-1]`)
- Les adresses venant de l'intérieur du VPN (`10.8.0.[0-255]`)
- Les adresses publiques des serveurs Opentalent (`141.94.117.[33-61]`)
- Les adresses privées des serveurs Opentalent (`172.16.0.[0-255]`)
- Les adresses des autres containers docker (`172.20.[0-255].[0-255]`)

> Plus d'infos ici : https://ressources.opentalent.fr/display/SI/Infrastructure+et+reseau


### 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 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 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é.

Les routes internal sont configurées ici : `config/packages/security.yaml`



### Valider le fonctionnement

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 | 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 |
| /api/internal/download/$id | OUI           | NON         | OUI        | 200 OK           |
| /api/internal/download/$id | OUI           | OUI         | OUI        | 200 OK           |
| /api/internal/download/$id | NON           | OUI         | OUI        | 200 OK           |
| /api/internal/download/$id | OUI           | OUI         | NON        | 403 Forbidden    |
| /api/download/$id          | *             | NON         | *          | 401 Unauthorized |
| /api/download/$id          | *             | OUI         | *          | 200 OK           |


Les mêmes tests s'appliquent côté V1, appliqués à un fichier stocké sur l'environnement de la V1.