Closed simonLouvet closed 2 years ago
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.
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.
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.
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.![image](https://user-images.githubusercontent.com/5068825/136397855-b035f2e9-18b0-47b7-b4d7-d5161d9b0fe6.png)
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 création ou édition d'un Equipement
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 contextelimite 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