Produits Entr'ouvert » Authentic 2

Paul Marillonnet a écrit :

C’est à mon avis typiquement le genre de chose qu’on voudrait pouvoir classer par collectivité (au sens OU) pour pouvoir restreindre les accès à l’API.
Un exemple parmi d’autres, un déploiement multi-collectivités où on veut ouvrir l’API sur l’une des collectivités et pas les autres.

Et en fait ça passe déjà nécessairement par des rôles de gestion dans les collectivités. Pas sûr qu’on gagne à ajouter quoi que ce soit ici, je vérifie et rejette le ticket ensuite.

Si, c’est sans doute quand même intéressant d’avoir des rôles de gestion des clients d’API cloisonnés à une collectivité. Ce serait purement a2, rien dans hobo ; lorsque la personne qui détient le rôle édite un client d’API, il faut vérifier que les rôles ajoutés ne sont pas en dehors de l’OU d’appartenance du rôle de gestion.

Paul Marillonnet a écrit :

Si, c’est sans doute quand même intéressant d’avoir des rôles de gestion des clients d’API cloisonnés à une collectivité. Ce serait purement a2, rien dans hobo ; lorsque la personne qui détient le rôle édite un client d’API, il faut vérifier que les rôles ajoutés ne sont pas en dehors de l’OU d’appartenance du rôle de gestion.

Et avec ça un autre bout intéressant : en finir avec les permissions globales dans l’API a2, et au lieu de ça filtrer automatiquement les querysets en fonction des permissions équivalentes par OU détenues par l’appelant.

Benjamin Dauvergne a écrit :

Je mettrai directement ou comme non-null et valeur par défaut get_default_ou(), aucune raison d'avoir des API client sans OU (on a déjà le souci sur les utilisateurs ne le reproduisons pas ici).

Mais justement je pensais que ces utilisateurs qui n’appartiennent à aucune OU ne vont être atteignables par aucun client d’API réduit à une OU, et que c’est justement la raison pour laquelle il faut tolérer que ces clients puissent ne pas avoir d’OU. Je loupe un truc ? Comment on ferait pour atteindre les utilisateurs sans OU sans cette possibilité APIClient.ou := null ?

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Je mettrai directement ou comme non-null et valeur par défaut get_default_ou(), aucune raison d'avoir des API client sans OU (on a déjà le souci sur les utilisateurs ne le reproduisons pas ici).

Mais justement je pensais que ces utilisateurs qui n’appartiennent à aucune OU ne vont être atteignables par aucun client d’API réduit à une OU, et que c’est justement la raison pour laquelle il faut tolérer que ces clients puissent ne pas avoir d’OU. Je loupe un truc ? Comment on ferait pour atteindre les utilisateurs sans OU sans cette possibilité APIClient.ou := null ?

Y a pas de lien entre APIClient.ou et les utilisateurs visibles ou alors je n'ai pas bien lu le patch. Si un APIClient veut voir tous les utilisateurs il faut lui filer la permission globale custom_user.search_user. Pour moi APIClient.ou c'est juste pour compartimenté l'administration des APIClient en BO.

Benjamin Dauvergne a écrit :

Y a pas de lien entre APIClient.ou et les utilisateurs visibles ou alors je n'ai pas bien lu le patch. Si un APIClient veut voir tous les utilisateurs il faut lui filer la permission globale custom_user.search_user. Pour moi APIClient.ou c'est juste pour compartimenté l'administration des APIClient en BO.

Ok, cette compartimentation peut être une première étape en effet.
À terme je pense qu’il faudrait tendre vers :

Il y aurait avec ça un autre patche (dans un futur cycle toujours) pour s’assurer dans le /manage/ qu’un gestionnaire des clients d’API d’une collectivité Lambda ne peut pas aller accorder des rôles avec des permissions globales ni des permissions d’une autre collectivité Gamma, seulement les permissions pour la collectivité Lambda (car c’est la collectivité d’appartenance du rôle de gestion de clients d’API qu’il détient).

(Dans le fil de discussion de la release du 8 décembre).

Automatic expiration