idp_oidc: add client_id & client_secret fields in edit form (#76224) #250

Open
yweber wants to merge 1 commits from wip/76224-enable-client-id-secret-edition-for-oidc-service into main
Owner
No description provided.
yweber force-pushed wip/76224-enable-client-id-secret-edition-for-oidc-service from 7582916a0e to 45726cd45b 2024-01-30 15:39:59 +01:00 Compare
yweber reviewed 2024-01-30 15:41:47 +01:00
@ -217,0 +221,4 @@
resp = app.get(f'/manage/services/{oidc_client.id}/settings/edit/')
form = resp.form
form['client_id'] = 'superid'
form['client_secret'] = 'hackme'
Author
Owner

Il faudrait peut être valider la valeur qui est passé en client_secret (client_id aussi ?) ?

Comment on test : la longueur ? la "complexité" ? on test que c'est bien un uuid ?

Il faudrait peut être valider la valeur qui est passé en client_secret (client_id aussi ?) ? Comment on test : la longueur ? la "complexité" ? on test que c'est bien un uuid ?
yweber changed title from WIP: idp_oidc: add client_id & client_secret fields in edit form (#76224) to idp_oidc: add client_id & client_secret fields in edit form (#76224) 2024-01-30 15:44:21 +01:00
Owner

Juste un bouton générer un nouveau secret suffira et le champ en lecture seule, pareil pour client_id je ne vois aucune raison de pouvoir le modifier librement (ou alors arrêter de l'auto généré).

Juste un bouton générer un nouveau secret suffira et le champ en lecture seule, pareil pour client_id je ne vois aucune raison de pouvoir le modifier librement (ou alors arrêter de l'auto généré).
Author
Owner

Juste un bouton générer un nouveau secret suffira et le champ en lecture seule, pareil pour client_id je ne vois aucune raison de pouvoir le modifier librement (ou alors arrêter de l'auto généré).

J'ai peut être mal compris la validité de la demande, mais le cas d'usage me semble détaillé en #75733 non ?

> Juste un bouton générer un nouveau secret suffira et le champ en lecture seule, pareil pour client_id je ne vois aucune raison de pouvoir le modifier librement (ou alors arrêter de l'auto généré). J'ai peut être mal compris la validité de la demande, mais le cas d'usage me semble détaillé en #75733 non ?
Owner

Juste un bouton générer un nouveau secret suffira et le champ en lecture seule, pareil pour client_id je ne vois aucune raison de pouvoir le modifier librement (ou alors arrêter de l'auto généré).

J'ai peut être mal compris la validité de la demande, mais le cas d'usage me semble détaillé en #75733 non ?

Je cite:

Ensuite, je crée des services pour le dev (pour l'utiliser avec une instance Plone en localhost). Ou je voudrais mettre un client_id et client_secret qui soit clairement un identifiant de dev (comme 11111111-1111-1111-1111-11111111111) car nous voulons utiliser un seul service de dev avec mes collègues (bcp plus simple à maintenir et à mettre en place) et pouvoir commiter ce client_{id/secret} dans notre gestionnaire de source sans croire que c'est un leak.

Je ne souhaite pas qu'on prenne la demande d'IMIO en compte, ils peuvent se débrouiller de en python pour créer un client de dév comme ça, c'est tout à fait spécifique à leur pratique locale et c'est simple à automatiser avec des fixtures Django. Par contre modifier le slug oui mais déjà fait dans #76223.

> > Juste un bouton générer un nouveau secret suffira et le champ en lecture seule, pareil pour client_id je ne vois aucune raison de pouvoir le modifier librement (ou alors arrêter de l'auto généré). > > J'ai peut être mal compris la validité de la demande, mais le cas d'usage me semble détaillé en #75733 non ? Je cite: ``` Ensuite, je crée des services pour le dev (pour l'utiliser avec une instance Plone en localhost). Ou je voudrais mettre un client_id et client_secret qui soit clairement un identifiant de dev (comme 11111111-1111-1111-1111-11111111111) car nous voulons utiliser un seul service de dev avec mes collègues (bcp plus simple à maintenir et à mettre en place) et pouvoir commiter ce client_{id/secret} dans notre gestionnaire de source sans croire que c'est un leak. ``` Je ne souhaite pas qu'on prenne la demande d'IMIO en compte, ils peuvent se débrouiller de en python pour créer un client de dév comme ça, c'est tout à fait spécifique à leur pratique locale et c'est simple à automatiser avec des fixtures Django. Par contre modifier le slug oui mais déjà fait dans #76223.
All checks were successful
gitea/authentic/pipeline/head This commit looks good
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b wip/76224-enable-client-id-secret-edition-for-oidc-service main
git pull origin wip/76224-enable-client-id-secret-edition-for-oidc-service

Step 2:

Merge the changes and update on Gitea.
git checkout main
git merge --no-ff wip/76224-enable-client-id-secret-edition-for-oidc-service
git push origin main
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/authentic#250
No description provided.