Produits Entr'ouvert » Authentic 2

(help)

Voici un premier jet qui permet d'avoir un rendu avec la présentation de type table.

Ce patch ne gère pas encore les permissions.
D'instinct j'aurais choisi d'utiliser la permission : "Supprimer / oidc authorization".
Mais, les permissions sont attachées à un backend et le backend oidc ne les implémente pas.
(Est-ce que quelqu'un aurait une piste pour m'aiguiller ?)

(Le rendu, sans la gestion des permissions)

• 0001 ajouter la permission après une migration, comme c'est fait pour pour l’opération VIEW_OP associée au modèle a2_rbac.role.
• 0002 ajouter un formulaire de suppression des autorisations oidc qui vérifie la permission
• 0003 reprend le premier patch donnée plus haut, en ajoutant une popup de confirmation et (c'est peut-être superflus) qui grise l’icône de suppression si un utilisateur qui n'a pas la permission arrive quand même sur la page.

Merci. J'en ai profité pour déplacer le patch du fichier tables.py dans 0003.

La vue ne déclarer pas de permission (attribut de classe permissions) et donc est visible de tous, je penser qu'un permission adéquat serait "custom_user.view_user" (la vue est visible à ceux qui voient aussi la vue de détail d'un utilisateur).

Je ne vois rien d'autre qui me choque.

J'ai du mal avec les permissions (Perm = opération / destination) et j'ai dû revoir mes patchs pour corriger mes erreurs :
dans le second commit précédent je faisais pointer les permissions sur les autorisations OAuth, alors qu'elles doivent pointer sur l'utilisateur affiché.

Ici, j'ai fusionné ces 2 commits : j'ai retiré la vérification des permissions sur les champs du formulaire (ça n'a pas sens) et j'ai ajouté la vérification des permission sur l'utilisateur cible, lors de la validation du formulaire.

(Je note au passage que pour créer les nouvelles permissions, pour tester le patch à l'usage par exemple, il faut faire une migration : lancer la commande "migrate_schemas" ne suffit pas si elle ne migre rien)

J'ai changé les noms des templates, classes, urls... en les préfixant par "user_oauth_services" (au lieu de "authorized_oauth_services")

Bouton à côté d'éditer

J'ai réduit l'intitulé du bouton à "Services authorizations".
J'aurais bien mis 'Oauth services" pour coller avec le reste mais je pense que ce n'est pas assez compréhensible.

virer {# avoid cycle for Django 1.2-1.6 compatibility #}

C'est du code copié/collé issu de src/authentic2/manager/templates/authentic2/manager/table.html que j’étends dans user_oauth_services_tables.html.
Je réalise que j'ai surchargé inutilement table.html pour retirer le lien sur la ligne, alors que je peux simplement l'invalider avec : '{% with row_link=0 %}'

Sinon, ce commentaire est introduit par le quatrième patch de #5180 qui met en place le fichier table.html. On retrouve le même code dans django_table2, sans le commentaire (que je n'arrive donc pas à élucider).
https://github.com/jieter/django-tables2/blob/master/django_tables2/templates/django_tables2/table.html#L27

Ça m'inquiète que tes tests passent alors que manage_auth_role n'a que la permission d'administration des autorisations (Généralement on définit un héritage...)

C'est parce que l'héritage était déjà en place, je l'ai fait en m'alignant sur manage_members (dans 0001) :

DJANGO_RBAC_PERMISSIONS_HIERARCHY = {
    'admin': ['change', 'delete', 'add', 'view', 'change_password', 'reset_password', 'activate',
    'manage_members': ['view', 'search'],
    'manage_authorizations': ['view', 'search'],
}

il faut faire une migration : lancer la commande "migrate_schemas" ne suffit pas si elle ne migre rien

Je note ici qu'il faudra vérifier que ce patch passera en même temps qu'une migration, ou alors qu'il faudrait que j'en génère une factice.

Nicolas Roche a écrit :

J'ai changé les noms des templates, classes, urls... en les préfixant par "user_oauth_services" (au lieu de "authorized_oauth_services")

Ça n'a pas de rapport avec oauth, user_authorizations ça suffirait.

Bouton à côté d'éditer

J'ai réduit l'intitulé du bouton à "Services authorizations".

Juste "Authorizations" ?

J'aurais bien mis 'Oauth services" pour coller avec le reste mais je pense que ce n'est pas assez compréhensible.

OAuth c'est un détail d'implémentation, n'en parlons nul part (on pourrait avoir des autorisations de SSO en SAML aussi).

virer {# avoid cycle for Django 1.2-1.6 compatibility #}

C'est du code copié/collé issu de src/authentic2/manager/templates/authentic2/manager/table.html que j’étends dans user_oauth_services_tables.html.
Je réalise que j'ai surchargé inutilement table.html pour retirer le lien sur la ligne, alors que je peux simplement l'invalider avec : '{% with row_link=0 %}'
Sinon, ce commentaire est introduit par le quatrième patch de #5180 qui met en place le fichier table.html. On retrouve le même code dans django_table2, sans le commentaire (que je n'arrive donc pas à élucider).
https://github.com/jieter/django-tables2/blob/master/django_tables2/templates/django_tables2/table.html#L27

Oublions, vire le commentaire simplement.

Ça m'inquiète que tes tests passent alors que manage_auth_role n'a que la permission d'administration des autorisations (Généralement on définit un héritage...)

C'est parce que l'héritage était déjà en place, je l'ai fait en m'alignant sur manage_members (dans 0001) :
[...]

Je suis rassuré :).

Mais faut-il rajouter les permissions 'manage_*' à 'admin' ?

Oui, on ne l'a pas vu mais elles manquent.

il faut faire une migration : lancer la commande "migrate_schemas" ne suffit pas si elle ne migre rien

Je note ici qu'il faudra vérifier que ce patch passera en même temps qu'une migration, ou alors qu'il faudrait que j'en génère une factice.

Je comprends maintenant ce que tu voulais dire; en voulant accélérer les migrations on fait une passe sur la table des migrations de chaque tenant pour décider de lancer ou pas la commande migrate sur le tenant, en ne lançant pas cette commande on perd le lancement des actions post-migrate (qui après les checks Django et peut-être encore ce qui nous coûte cher). Un moyen d'obtenir quand même le post-migrate c'est de lancer migrate_schemas uniquement sur l'app authentic2, ça désactive « l'optimisation »[1].

¹ https://git.entrouvert.org/hobo.git/tree/hobo/multitenant/management/commands/migrate_schemas.py#n60

Rapidement relu, en dehors des OAuth/oauth partout c'est bon.

Oups, oui en effet.
J'ai corrigé le test de 0001 qui ne passait plus suite à l'ajout de la permission 'manage_authorizations' à 'admin'.

Wunderbar.

commit 14f37aeedd6a349d3ae93616591be0337770b548
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Thu Sep 10 12:31:53 2020 +0200

    manager: add a page to manage users authorized services (#46182)

commit c636b164242bd9e88f06bc8ae330ed73a16549ca
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Thu Sep 10 12:24:42 2020 +0200

    a2_rbac: add manage_authorizations permission to custom_user (#46182)