# Internal Requests

### Principe général

Les requêtes internes sont des requêtes envoyées de ap2i vers opentalent-platform ou dans le sens inverse, par 
exemple pour demander un fichier.

Ces requêtes ne sont pas 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 à la présence d'un token
* on limite les routes concernées

Ainsi, si l'on prend l'exemple d'une requête `/internal/download/123` sur ap2i :

* Un utilisateur dans le VPN qui ferait un curl à cette adresse recevra une erreur 500 à cause du token manquant
* Un utilisateur hors VPN, même s'il connaissait le token, recevra une erreur 500, car n'ayant pas une ip autorisée
* Une requête issue de la V1 sera autorisée sans authentification

### 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 deux API ou à d'autres éventuels échanges entre systèmes.

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.

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

Soit `$id` 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 |
|----------------------------|---------------|-------------|------------|------------------|
| /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 | OUI           | OUI         | NON        | 403 Forbidden    |
| /api/internal/download/$id | NON           | OUI         | OUI        | 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.