Development #38365
Ajouter un controle d'accès aux endpoints des connecteurs par rôle
0%
Description
Pour éviter le cas typique :
- besoin de tester un endpoint dans un navigateur
- j'ouvre le connecteur à tous vents
- j'oublie de rétablir le contrôle d'accès normal après mon test
Fichiers
Révisions associées
Historique
Mis à jour par Valentin Deniaud il y a plus de 4 ans
- Fichier 0001-base-grant-endpoint-permissions-using-roles-38365.patch 0001-base-grant-endpoint-permissions-using-roles-38365.patch ajouté
- Patch proposed changé de Non à Oui
Mis à jour par Frédéric Péters il y a plus de 4 ans
Je ne sais pas si c'est ça qu'avait en tête Emmanuel; de mon côté j'imaginais simplement permettre l'accès aux endpoints à l'admin, inconditionnellement.
Mis à jour par Valentin Deniaud il y a plus de 4 ans
Il va dire, mais ça me paraissait sans ambiguïté. Maintenant sûrement que ce que tu proposes est suffisant pour le cas d'usage évoqué, je laisse Manu trancher.
(j'étais en train d'écrire :)
C'est du wip qui wfm™, mais je veux bien un avis sur l'approche avant d'écrire les tests et de fignoler.
Notamment : un contrôle d'accès par rôles, c'est presque pareil qu'un contrôle d'accès par utilisateur d'api. Du coup, c'est un champ qui change dans le modèle, et par ruissellement un changement dans chaque formulaire, dans chaque vues, dans chaque template. Ça crie très fort duplication de code.
Pour la mitiger j'ai rajouté des classes abstraites là où c'était possible. Ma question c'est, est-ce qu'il faut aller plus loin et tout faire dans le modèle AccessRight, en remplaçant apiuser par une GenericForeignKey ? Ça limiterait au max la duplication, mais pas sûr qu'on économise beaucoup de lignes au final (dès qu'il faudra faire de l'affichage on aurait des disjonctions de cas chiantes à gérer, notamment pour le formulaire). Et aussi un code moins facile à lire.
Mis à jour par Frédéric Péters il y a plus de 4 ans
Ce que je crains avec ce contrôle d'accès par rôle c'est qu'il laisse penser qu'il puisse y avoir vérification du rôle de l'"utilisateur" appelant, "utilisateur" qui serait l'agent dans une démarche dans w.c.s.
Mis à jour par Emmanuel Cazenave il y a plus de 4 ans
Oups désolé si je t'ai lancé sur une fausse piste Valentin, j'ai mis "rôle" pour faire intelligent mais je pensais juste aux admins, j'aurais du m'abstenir avec ce mot.
L'accès inconditionnels aux admins me parait bien suffisant pour le cas d'usage.
Mis à jour par Thomas Noël il y a plus de 4 ans
(Pour le coup il n'ose pas le dire, mais c'est moi qui a enduit Valentin d'erreur en causant de ce ticket ce matin)
(Enfin, non, je dis n'importe quoi : c'était hier matin)
Mis à jour par Valentin Deniaud il y a plus de 4 ans
Mis à jour par Valentin Deniaud il y a plus de 4 ans
Mis à jour par Valentin Deniaud il y a plus de 4 ans
- Statut changé de Nouveau à Solution proposée
(git redmine a eu la flemme de changer le statut, on dirait)
Mis à jour par Emmanuel Cazenave il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Yes (pour le prochain cycle).
Mis à jour par Thomas Noël il y a plus de 4 ans
Un truc ça serait que ça ne marche pas pour les JSONP, mais bon, ça semble pas simple, là, comme ça. (Pour éviter que tout marche bien pour les admin, mais pas pour les agents ou usagers)
Mis à jour par Valentin Deniaud il y a plus de 4 ans
commit d2d7aaf29472ff063f8b052877a2caa6e2b0f48e Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Dec 12 10:20:34 2019 +0100 utils: authorize admin access to all endpoints (#38365)
Mis à jour par Valentin Deniaud il y a plus de 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
utils: authorize admin access to all endpoints (#38365)