Project

General

Profile

Development #91914

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

Added by Thomas Noël (congés → 2 septembre) 30 days ago. Updated 20 days ago.

Status:
En cours
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 - Development #92023: Conditionner l'accès aux API en fonction des roles du clientEn cours19 June 2024

Actions
Related to Authentic 2 - Development #92548: Renvoyer l'information is_superuser par service pour les APIClientsSolution déployée02 July 2024

Actions

History

#1

Updated by Yann Weber 29 days 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 (congés → 2 septembre) 29 days 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 29 days 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 29 days ago

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

Updated by Yann Weber 28 days ago

  • Related to Development #92023: Conditionner l'accès aux API en fonction des roles du client added
#6

Updated by Robot Gitea 20 days 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 15 days ago

  • Related to Development #92548: Renvoyer l'information is_superuser par service pour les APIClients added

Also available in: Atom PDF