Projet

Général

Profil

Development #75391

Le champ OIDCClient.scope n'est plus éditable

Ajouté par Benjamin Dauvergne il y a environ un an. Mis à jour il y a environ un an.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
13 mars 2023
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Il n'est pas dans le formulaire d'édition des services OIDC (dans authentic2_idp_oidc.manager.forms), il faudra recontrôler tous les champs par rapport à ce qui était visible dans l'admin avant.

Tout était visible je pense :

-class OIDCClientAdmin(admin.ModelAdmin):
-    list_display = [
-        'name',
-        'slug',
-        'client_id',
-        'ou',
-        'identifier_policy',
-        'created',
-        'modified',
-        'activate_user_profiles',
-    ]
-    list_filter = ['ou', 'identifier_policy']
-    date_hierarchy = 'modified'
-    readonly_fields = ['created', 'modified']
-    inlines = [OIDCClaimInlineAdmin]

Historique

#1

Mis à jour par Paul Marillonnet il y a environ un an

Plus logiquement, il faudrait que ce champ soit constitué implicitement en tant que regroupement de chacun des scopes associés aux claims déclarés pour ce client, non ?

#2

Mis à jour par Benjamin Dauvergne il y a environ un an

Non parce qu'on peut vouloir accepter un scope sans répondre aucun claims supplémentaire en échange (parce que le RP est difficilement reconfigurable).

#3

Mis à jour par Paul Marillonnet il y a environ un an

Je crois que dans ce cas là on peut de notre côté silencieusement ignorer ces scopes qui ne sont associées à aucun claim (de mémoire, c’est dans le spécs OAuth2 qu’on précise que l’implémentation serveur peut claquer une erreur ou bien ignorer les scopes incongrus ou pas autorisés).

#4

Mis à jour par Benjamin Dauvergne il y a environ un an

Ça c'est autre chose, tu peux ouvrir un autre ticket pour arrêter de péter une erreur sur un scope en trop pour simplement l'ignorer, mais on aura toujours besoin d'avoir une autorisation de scope exclusive ne serait que pour que modify_user_info puisse être étendu, les scopes ne servent pas forcément qu'aux claims. Pour moi le code actuel à des usages prévus, je ne vois pas de problème à laisser ce champ vide par défaut pour les usages supplémentaires. Par contre on peut prévoir dans ce ticket de rappeler dans l'interface les scopes qui ne seront pas ignorés en cours (et les restreindre à ceux des claims si pas mieux).

Formats disponibles : Atom PDF