Project

General

Profile

Développement #91914

retirer hobo.rest_authentication.APIClientAuthentication ou l'utiliser plus finement (gestion des rôles)

Added by Thomas Noël 8 months ago. Updated about 1 month ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
17 June 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

On a dans REST_FRAMEWORK['DEFAULT_AUTHENTICATION_CLASSES'] mention de « hobo.rest_authentication.APIClientAuthentication » et cela ouvre trop l'accès aux API.

Comme ces API sont actuellement utilisées uniquement en interne Publik, je propose de retirer cette classe d'authentification DRF.

Ou alors, d'au moins limiter l'accès aux API aux clients d'API qui ont le rôle "administrateur de chrono".

(Plus tard, tickets à faire pour ouvrir les APIs en fonction des rôles du client d'API, selon les rôles de lecture/écriture/administration/modification/etc sur un agenda donné)


Related issues

Related to Chrono - Développement #92023: Conditionner l'accès aux API en fonction des roles du clientRejeté19 June 2024

Actions
Related to Authentic 2 - Développement #92548: Renvoyer l'information is_superuser par service pour les APIClientsFermé02 July 2024

Actions
Related to Hobo - Développement #92621: Clients d'API : implémenter des permissions DRF pour les autres servicesFermé03 July 2024

Actions

History

#1

Updated by Yann Weber 8 months ago

J'ai rapidement regardé, il me semble que hobo.rest_authentication.APIClientAuthentication renvoie un hobo.rest_authentication.APIClientUser disposant d'un attribut roles : une liste des roles attribués au client d'API.

Est-ce qu'une solution pourrait être de tester l'existence du rôle _a2-hobo-superuser (c'est l'identifiant court que j'ai trouvé pour "Administrateur des agendas") et n'autoriser l'accès a un client d'API que dans ce cas la ?

#2

Updated by Thomas Noël 8 months ago

Yann Weber a écrit :

Est-ce qu'une solution pourrait être de tester l'existence du rôle _a2-hobo-superuser (c'est l'identifiant court que j'ai trouvé pour "Administrateur des agendas") et n'autoriser l'accès a un client d'API que dans ce cas la ?

Il semble que cet identifiant est bogué (tous les rôles admin ont le même). Ne comptons pas dessus.

Ce qui serait préférable selon moi, c'est que quand un service interroge l'API /check-api-user/, Authentic regarde si le client d'API dispose du rôle « Administrateur de [ce service] ». Comme on le fait pour le provisionning. Authentic renverrait alors un « is_superuser » correct (au lieu de False actuellement) sur lequel on pourrait effectivement baser l'ouverture de nos API ou non.

Si c'est trop difficile (et/ou si le code rendu est illisible), il faut rester sur une gestion par rôles. On a sur un agenda admin_role/edit_role/view_role : je verrais bien l'ajout d'un api_role, qui me semblerait sans ambiguïté. Je pense que cette solution aurait ma préférence.

#3

Updated by Robot Gitea 8 months ago

  • Status changed from Nouveau to En cours
  • Assignee set to Yann Weber

Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :

#4

Updated by Robot Gitea 8 months ago

  • Status changed from En cours to Solution proposée
#5

Updated by Yann Weber 8 months ago

#6

Updated by Robot Gitea 8 months ago

  • Status changed from Solution proposée to En cours

Yann Weber (yweber) a commencé à travailler sur une pull request sur Gitea concernant cette demande :

#7

Updated by Yann Weber 8 months ago

  • Related to Développement #92548: Renvoyer l'information is_superuser par service pour les APIClients added
#8

Updated by Yann Weber 7 months ago

  • Related to Développement #92621: Clients d'API : implémenter des permissions DRF pour les autres services added
#9

Updated by Robot Gitea 6 months ago

Yann Weber (yweber) a fermé une pull request sur Gitea concernant cette demande.

#10

Updated by Robot Gitea 6 months ago

Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :

#11

Updated by Robot Gitea 4 months ago

  • Status changed from En cours to Solution proposée
#12

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution proposée to Solution validée

Benjamin Dauvergne (bdauvergne) a approuvé une pull request sur Gitea concernant cette demande :

#13

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution validée to Résolu (à déployer)

Yann Weber (yweber) a mergé une pull request sur Gitea concernant cette demande :

#14

Updated by Transition automatique about 1 month ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF