utiliser les écrans spécifiques aux ressource pour editer les données des tiers lieux

[simonLouvet]

contexte

Pour éditer les entités (Equipement, Espace, Service) liés au tiers lieux, nous étions parti sur des ArrayIput (encapsulé dans de ReificationArrayInput) pour éditer/créer/supprimer comme une liste éditable.

Apres un correctif sur le middleware pour supporter les mise à jour avec disassembly, le fonctionnment générale semble ok mais nous subissons des erreurs react (react-admin je suppose) qui font planter l'app sans comprndre pourquois dans des cas différents et un rafraîchissement de page montre bien que les datas sont ok. L’équipe change donc d'orientation en s'inspirant de la création d'entité relative à une autre préconisé par react-admin.

spécification fonctionnelle

Pour éditer les Equipement d'un tiers lieux

• en mode edition sur un tiers lieux
• les Equipements apparaissent comme une liste non éditable
• un bouton permet d’éditer un équipement
• un bouton permet de supprimer un équipement
• un bouton permet de créer un equippement
• la création et l’édition d'un équipement se fait par naviguation sur l’édition ou la création de la ressource Equipement avec un contexte dans l'url
• même fonctionnement pour Espace et Service

En création ou édition d'un Equipement

• si pas de contexte contenant un tiers lieux -> redirection vers les la liste des tiers lieux
• si un contexte contenant le tiers lieux : vérification des droits du user sur ce tiers lieux; si pas les droits -> redirection vers le tiers lieux en lecture
• si contexte et droits
  • ne pas afficher le input de l'Equipement qui contient le tiers lieux (champ caché) mais l’initialiser avec le contexte
  • redirection vers le tiers lieux en édition suite à enregistrement
• même fonctionnement pour Espace et Service

spécification technique

Le contexte sera fourni dans l'url en urlEncoded sur la même logique que le filter react-admin. exemple
https://app/Equipement/equipmentId?redirectUri=urlFromOrga
https://app/Equipement/create?source={petr:equipmentOfferedBy:uriOfOrganization}&redirectUri=urlFromOrga
La redirection après édition/création fait disparaitre le querystring/search ci dessus.
utiliser @semapp/auth-provider/useCheckPermissions ou react-admin/useGetPermissions ou react-admin/useAuthProvider pour determiné si le user à le droit de créer ou d'editer un Equipement du tiers-lieux passé dans la contexte

limite et probleme non résolu

Cette implémentation n'est pas pleinement sécurisé contre une malveillance d'un utilisateur qui pourrait réaliser une création d'Equipement lié à une orga en LDP POST directement. En effet aucune règle de sécurité n’empêche un utilisateur de créer cette ressource. L'inference n'est pas censé créer de lien inverse du tiers lieux vers l’équipement car l'utilisateur n'a pas de droits sur le tiers lieux. Un GET LDP sur le tiers ne devrait remonter l’équipement créé. Par conséquent, une navigation sur l'organisation ne devrait donc pas faire apparaître l'Equipement ainsi créé même si il est lié au tiers lieux. Cependant les triplets existeront en base de donnée et une requête SPARQL (via Sparnatural par ex) retournera l’équipement et le lien avec le tiers lieux.
Ce probleme pourrait être résolu par une amélioration du middleware

• solution généraliste : le service LDP émet un evénement avant de créer/modifier/supprimer une entité de manière à pouvoir capter cet événement et faire du code custom dans un service dédié. Ce code custom déclencherai une exception si les règles écrite dans ce code n'autorise pas l'opération. Ce code pourrait également modifié la donnée avant création/modification. Il est nécessaire que le service LDP principale soit synchrone avec la résolution de l’événement (attendre la fin du code custom).
• solution plus fine : le service AUTH émet un événement avant de résoudre la vérification de droits. un code custom dans un service dédié remplace la vérification de droits

[nikoPLP]

question reposée ici , avec la reponse initiale de Simon :
je comprends l'UX souhaitée et je n'ai pas d'avis sur son implementation en react admin. par contre je ne comprends pas trop le probleme de permission. en quoi les webACL ne permettent pas de gerer les droits de creation d'un equipement?
@simonLouvet :
par ce que le besoin est de gérer des droits sur le tiers lieux (organization, objet principale) et que les droits sur le Equipements soit identiques. Ca va,même un peut plus loin : créer un équipement lié à un tiers lieux nécessite d'avoir les droits sur ce tiers-lieux.

[srosset81]

Cette implémentation n'est pas pleinement sécurisé contre une malveillance d'un utilisateur qui pourrait réaliser une création d'Equipement lié à une orga en LDP POST directement. En effet aucune règle de sécurité n’empêche un utilisateur de créer cette ressource.

Je note que même avec l'autre solution (les relations "réifiées"), le problème aurait été le même.

L'inference n'est pas censé créer de lien inverse du tiers lieux vers l’équipement car l'utilisateur n'a pas de droits sur le tiers lieux.

Actuellement tous les liens inverses sont ajoutés avec un webId system donc les droits ne sont pas vérifiés.

https://github.com/assemblee-virtuelle/semapps/blob/master/src/middleware/packages/inference/service.js

Concernant l'amélioration du middleware, je fais remarquer que c'est un problème général avec l'implémentation actuelle de SemApps: les données ne sont pas vérifiées. Tant que SHACL/SHeX ne sont pas implémentés, les utilisateurs peuvent poster n'importe quoi dans n'importe quel container (surtout s'ils savent faire du POST directement). Et cela peut créer des failles, du moins dans l'affichage. Du coup je ne sais pas si ça vaut la peine de s'occuper de cette faille de sécurité minime.