706 [SENSITIVE ENTRANCE] Special treatment

[Clm-Roig]

Fix #706
#695 can be done with the same pattern.

⚠️ Breaking changes (voir plus bas)

Description de la PR

• Création d'un helper remove-sensitive-entrances
• Celui-ci cherche tous les attributs comprenant les termes entrances (tableau) et entrance (objet). La recherche du terme est effectuée avec les fonctions toLowerCase() et endsWith() des String. De ce fait, on capture les collections comme exploredEntrances avec le terme entrances.
• Ce helper est appelé automatiquement par la réponse custom ok() et filtre les données selon la logique suivante :
  • Si l'utilisateur peut voir les entrées sensibles de manière "complète" (admin), rien n'est filtré.
  • Si l'utilisateur peut voir les entrées sensibles de manière "limitée" (utilisateur), les attributs locations, longitude et latitude sont supprimés.
  • Si l'utilisateur ne peut voir les entrées sensibles (visiteur), les entrées sont supprimées.

Implication importante

Désormais, toutes les réponses renvoyant des données (hors erreurs) à l'utilisateur (code 200 généralement), doivent impérativement passer par la réponse custom ok(). On ne doit plus faire de return res.json() qui va bypasser notre système de filtrage.

La seule route qui le fait actuellement, ce sont les routes "Geoloc" qui permettent d'obtenir les entrées sur la carte. Je peux éventuellement remanier le code pour qu'elles utilisent aussi ok().

BREAKING CHANGES

Certaines routes (find all licenses, find all options...) renvoyaient un tableau de résultat en JSON sans clé. Or, j'ai besoin, pour filtrer, d'avoir un objet à la racine de mes données. Leur résultat est donc devenu un objet avec la clé licenses par exemple.

Résultat de GET /licenses avant :

[{
  id: 1,
  // ...
}, {
  id: 2,
  // ...
}]

Résultat de GET /licenses désormais :

{
  licenses: [
    {
      id: 1,
      // ...
    }, {
      id: 2,
      // ...
    }
]

Ces changements vont casser le front évidemment. Je ferai les changements du front appropriés "à la volée" quand on déploiera l'API avec cette PR.

[urien]

Le résultat sera différent de ce qui avait été indiqué dans #706 et ce qu'on a annoncé à l'UIS.
Ce qui avait été envisagé c'est que les cavités "sensibles" soient accessibles avec des coordonnées faussées correspondant au centroide de la commune sur laquelle se situe la cavité
On trouve des apis qui fournissent ce service, une liste est accessible ici https://github.com/public-apis/public-apis#geocoding
Je pense qu'une fois que les coordonnées sont faussées (ou ne sont pas fournies si c'est finalement la solution mise en oeuvre) il ne doit pas y avoir de restriction d’accès aux cavités, les visiteurs peuvent accéder aux cavités sensibles, de manière a ce que les structures qui utilisent nos apis aient accès à ces informations.

Si le résultat est différent de ce qui avait été annoncé initialement, il faudra qu'on l'explique à l'UIS, le courrier qui doit être envoyé dans quelques jours aux fédérations et le texte d'introduction figurant sur le forum de l'UIS seront à modifier.

[Clm-Roig]

Ce qui avait été envisagé c'est que les cavités "sensibles" soient accessibles avec des coordonnées faussées correspondant au centroide de la commune sur laquelle se situe la cavité

Ça n'a pas été inclus dans mon devis, faute de budget.

On trouve des apis qui fournissent ce service, une liste est accessible ici https://github.com/public-apis/public-apis#geocoding

Quid de #271 et #273 dont c'était le but ?

il ne doit pas y avoir de restriction d’accès aux cavités, les visiteurs peuvent accéder aux cavités sensibles, de manière a ce que les structures qui utilisent nos apis aient accès à ces informations.

Je peux modifier ça rapidement si tu veux, pas de problème.