Project

General

Profile

Développement #92023

Conditionner l'accès aux API en fonction des roles du client

Added by Yann Weber 9 months ago. Updated 2 months ago.

Status:
Rejeté
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
19 June 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

La suite de #91914 :

Il faudrait que l'accès aux API soit ouvert en fonction des rôles d'administration/édition/visualisation des agendas.


Related issues

Related to Chrono - Développement #91914: retirer hobo.rest_authentication.APIClientAuthentication ou l'utiliser plus finement (gestion des rôles)Fermé17 June 2024

Actions
Related to Hobo - Développement #93761: Enrichir les permissions DRF pour les conditionner au rôle d'un client d'APIFermé01 August 2024

Actions

History

#1

Updated by Yann Weber 9 months ago

  • Related to Développement #91914: retirer hobo.rest_authentication.APIClientAuthentication ou l'utiliser plus finement (gestion des rôles) added
#2

Updated by Robot Gitea 9 months ago

  • Status changed from Nouveau to En cours

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

#3

Updated by Yann Weber 8 months ago

  • Related to Développement #93761: Enrichir les permissions DRF pour les conditionner au rôle d'un client d'API added
#4

Updated by Robot Gitea 7 months ago

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

#5

Updated by Thomas Noël 2 months ago

  • Status changed from En cours to Rejeté

Cette fonctionnalité ne sera certainement jamais utilisée, les API de Chrono étant toujours utilisées par Publik uniquement.

On ne passe même pas en priorité basse, on rejette.

#6

Updated by Benjamin Dauvergne 2 months ago

  • Status changed from Rejeté to Information nécessaire

Thomas Noël a écrit :

Cette fonctionnalité ne sera certainement jamais utilisée, les API de Chrono étant toujours utilisées par Publik uniquement.

On ne passe même pas en priorité basse, on rejette.

Si c'est le cas alors il faut retirer APIClientAuthentication de settings.REST_FRAMEWORK['DEFAULT_AUTHENTICATION_CLASSES'] dans chrono/debian/debian_config.py. Je ne sais pas ce qu'il en est.

#7

Updated by Benjamin Dauvergne 2 months ago

Si je prends le cas de EventsAgendaFillslot qui est configuré comme ceci:

 permission_classes = (permissions.IsAuthenticated,)

a priori si APIClientAuthentication est déclaré dans les classes d'authentification, alors n'importe quel APIClient peut faire un fillslot ici (à moins qu'un truc m'échappe).

#8

Updated by Yann Weber 2 months ago

Benjamin Dauvergne a écrit :

Si c'est le cas alors il faut retirer APIClientAuthentication de settings.REST_FRAMEWORK['DEFAULT_AUTHENTICATION_CLASSES'] dans chrono/debian/debian_config.py. Je ne sais pas ce qu'il en est.

Dans ce ticket il était question de faire que l'accès aux API chrono respecte l'attribution des rôles d'un client d'API, le APIClientAuthentication dans le settings va néanmoins permettre de limiter l'accès aux API chrono aux client d'API qui sont admin de chrono ( #91914 ).

Discuté avec Thomas N. on s'est dit que la limitation aux client d'API avec les droits d'admin était suffisante pour le moment, et qu'on pourrait ré-ouvrir un ticket équivalent à celui-ci le jour on aura une demande qui ira dans le sens de contrôler l'accès des clients d'API aux API chrono plus finement.

#9

Updated by Benjamin Dauvergne 2 months ago

  • Status changed from Information nécessaire to Rejeté

Ok je me mélangeais les pinceaux avec le code d'origine montré par la PR de ce ticket mais qui ne montre pas le code actuel issue de #91914, tout va bien (enfin j'espère). Vu avec Thomas par jabber.

Also available in: Atom PDF