search

ecotaxa / ecopart

A web application dedicated to particle data from UVP and LISST.
Other
0 stars 1 forks source link

Contrôle des accès après la séparation d'EcoTaxa #31

Open jiho opened 3 years ago

jiho commented 3 years ago

@laurent-n :

Dans la cadre de la séparation, se pose le problème de la gestion de la visibilité. J'ai quelques question pour vous.

Actuellement la visibilité est gérée par :

Pour les 2 premiers, pas de problème, par contre le 3ème est lié à EcoTaxa et pose problème. Il me parait difficilement envisageable de faire des requêtes sur les diverses instances Ecotaxa en temps réel. Option 1) on fait une réplication périodique des privilèges Ecotaxa, mais on a potentiellement le problème de ne pas être sûr que les gens dans EcoPart sont bien les mêmes gens dans EcoTaxa (cf § gestion des login) Option 2) on gère une table de privilège associé à chaque projet EcoPart qui sera initialisé lors du split avec les privilèges présents dans EcoTaxa ==> Je penche pour l'option 2

Gestion des utilisateurs EcoPart : Lors du split j’imagine importer les utilisateurs qui sont en lien avec un projet EcoPart avec leur privilèges. Aujourd’hui pour créer un projet EcoPart il faut avoir le privilège Project Creator de EcoTaxa. Que fait-on pour la création de nouveaux utilisateurs ? Comme dans EcoTaxa, ils se créent tout seul ? Risque d’usurpation d’identité si les droits d'ecotaxa sont ramené automatiquement ! On les réplique depuis la base EcoTaxa ? ça peut avoir du sens tant qu’il n’y en a qu’une.

Définition de visibilité: @laurent-n : Sur des données EcoPart il est possible de

Il y a un système avec 3 dates qui pemet de donner des niveau de visibilité a tous le monde au fil du temps, auquel s'ajoute des privilèges issus des droits sur le projet EcoTaxa associé.

jiho commented 3 years ago

Pour les données UVP, l'import se fera exclusivement via EcoPart et l'objectif à terme est que EcoPart pousse les données image vers EcoTaxa. Donc la gestion des droits d'accès à l'ensemble de données particules + images doit se faire complètement côté EcoPart et pas côté EcoTaxa.

À terme cela veut dire qu'il faudra que lorsqu'un nouvel utilisateur EcoPart crée un projet avec une composante image et importe ses données: il soit créé en tant qu'utilisateur Ecotaxa un projet EcoTaxa soit crée avec lui comme manager et contact les données y soient poussées.

Ensuite, si des permissions sont rajoutées côtés EcoPart, ces utilisateurs devront également être poussés vers EcoTaxa et leur permissions mises à qq chose de compatible (manager ou annotator probablement; il faut définir un mapping des rôles EcoPart vers les rôles EcoTaxa).

On peut tout à fait imaginer que des personnes supplémentaires soient rajoutées côté EcoTaxa mais pas côté EcoPart et dans ce cas elles n'auront accès qu'aux données d'images, via EcoTaxa, pas à celles de particules et voilà. C'est un use case crédible.

Ce que je vois comme problématique là c'est:

Qu'en pensez-vous?

laurent-n commented 3 years ago

En lisant les réponses de JOI sur la création du projet EcoTaxa depuis EcoPart et les synchros, Je me questionne sur la pertinence de séparer les bases EcoPart et EcoTaxa ? Le fait d'avoir des systèmes qui gère des droits avec des identités non fédérées me semble introduire des problèmes.

Est ce que les raisons qui nous conduisent aujourd'hui à envisager plusieurs instances EcoTaxa ne risque pas de se poser rapidement avec un EcoPart unique et donc de se retrouver à terme à gérer un EcoPart par EcoTaxa et donc on se retrouverai aujourd'hui à chercher des solutions à des problèmes qui ne se poserais pas si on laissais les bases EcoPart et EcoTaxa liées. Peut être la piste d'un aggregateur d'EcoPart qui aurait la partie publique similaire à ce qu'on à aujourd'hui et qui serait alimenté par des synchro sélective serait intéressante. Ou un système de réplication sélective multimaitre.

Pour l'instant j'ai travaillé sur la séparation des logiciels et la mise en place de tests, là je commence à analyser plus précisément les impacts de séparer les bases. La semaine dernière on a discuté avec Laurent S. d'un moyen de récupérer les données sample et taxe et on a conclu qu'une user EcoPart aurait le droit de tout voir et qu'il fallait que je verrouille du mieux possible coté EcoPart la création du lien avec le projet EcoTaxa.

grololo06 commented 3 years ago

Méthodo: Effectivement on ne peut pas appliquer dans ce projet d'assignation multiple, comme on fait pour EcoTaxa quand il y a des points à discuter. Je crains que l'effort pour canaliser les discussions ne finisse dans les oubliettes.

grololo06 commented 3 years ago

Sur le fond, je n'ai rien contre laisser, dans cette première phase, les deux applis plutôt liées. Mais, comme posé ici: https://github.com/ecotaxa/ecopart/issues/23#issuecomment-696511264 , ligne "An interface file for data/events to/from EcoTaxa" il faut que l'interface vers EcoTaxa soit isolée. En terme techniques, elle ne prend que des données de base (JSON-compatible) et ne renvoie que des données du même acabit, qu'on peut simuler (mock) pendant les tests. Conséquence bénéfique: lors des évolutions d'EcoTaxa, il suffira de regarder cet "interface file" pour savoir l'impact sur EcoPart d'éventuels changements.

Evidemment si cet "interface file" ne contenait que des appels à l'API ce serait optimal, mais on peut envisager d'autres méthodes d'accès pour l'instant. Je vois https://github.com/ecotaxa/ecopart/blob/master/py/appli/part/ecotaxainterface.py qui est pas mal, mais:

Je m'attends à voir dans le fichier d'interface plein d'autres primitives, qui correspondent aux "besoins" d'EcoPart en matière de données/actions EcoTaxa.

laurent-n commented 3 years ago

Dans GetObjectsForTaxoHistoCompute c'est volontaire de passer l'objet car j'imagine que le projet contiendrai la référence de l'instance, cette fonction est libre de prendre les morceaux qu'elle à besoin pour les mettre dans l'appel à l'API

GetObjectsForRawExport pour l'instant c'est une jointure, l'idée est que ça deviendrai un appel API mais du point de vue de la fonction appellante ça serait transparent.

Pour la partie des droits soulevée dans cette issue c'est pour l'instant géré par des jointures, ce qui pourrait persister si on déporte la gestion des droits dans EcoPart, donc pas intéressant de le transformer en code python moins efficace.

La façon dé découper depend de l'objectif à la fin sur certains points. Par exemple si c'est découplé les noms des projets EcoTaxa seront dupliqué dans la table des projets EcoPart alors qu'aujourd'hui c'est fait par une jointure. Il n'y a pas d'interet à mettre un tel appel dans une module d'interface puisque à la fin ce n'est pas l'interface qui existerai.

Il faut décider ce qu'on fait à court terme en terme de split. Est ce qu'on veut absolument séparer les bases parce que vous êtes sur que c'est ce qu'il faudra faire à terme. Si vous n'êtes pas complètement sur ou pas totalement clair sur certains points, rester sur une base partagée serait peut être mieux à court terme.

grololo06 commented 3 years ago

Les données sont séparées logiquement même si elles ne le sont pas (encore) physiquement. Je propose, pour l'écriture des en-têtes des def du fichier d'interface, de considérer le pire cas, où les 2 applications sont sur des machines distinctes avec une connectivité non-fiable (Internet). D'où mon exigence sur le JSON-compatible (et le fait que les appels de ces primitives peuvent échouer temporairement). Effectivement ça peut apparaître comme un gaspillage de ressources, mais toute séparation a un prix.