-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Faciliter les développements en intégration/dev pour les API France Connectées #15
Comments
Si je résume: il faudrait que notre système de récupération des données FranceConnect tente de taper sur la version de test de FranceConnect avec le bearer token. L'idée est intéressante, mais peut-être un poil complexe. Pourquoi on ne s'arrête pas à juste faire le call sur la version de dev de FranceConnect, et faire matcher les données de la database. Avec ton exemple, on mettrait comme payload pour le statut étudiant: ---
params:
given_name: "Angela Claise Louise"
family_name: "Dubois"
birthdate: "1962-08-24"
gender: "female"
birthplace: "75107"
status: 200
payload: |-
{
"dateNaissance" : "1962-08-24",
"ine" : "1234567890T",
"inscriptions" : [
{
"codeCommune" : "33063",
"dateDebutInscription" : "2020-07-01",
"dateFinInscription" : "2021-08-31",
"etablissement" : {
"nomEtablissement" : "LYCEE GENERAL ET TECHNOLOGIQUE CAMILLE JULLIAN",
"uai" : "0330023W"
},
"regime" : "formation initiale",
"statut" : "inscrit"
}
],
"nomFamille" : "DUBOIS",
"prenom" : "Angela"
} Avec une itération sur le README + du bon naming sur les payloads (voir même un lien vers la ligne correspondante dans la database) je pense que c'est une itération suffisante pour faire du E2E ? |
Je pensais que c'était possible mais FC en dev respecte les scopes fournis. Dans mon cas, je n'ai que email, birthdate et sub comme scope et donc champs dans le payload réponse de FC. Ça semble donc impossible de faire un match sur les propriétés non récupérées (et en plus j'aime pas trop les matchs sur des champs pas nécessairement unique, même si dans ce cas j'étais près à jouer la carte de la simplification). Je suis d'accord avec toi, c'est un peu compliqué mais je ne vois pas trop comment faire de mieux. J'ai écrit au support partenaire de FC pour leur demander si les sub (pour le clientid/secret public) pouvaient être ajoutés à la database (pour améliorer la découvrabilité des profils avec des données intéressantes). |
Comment ça ? En parlant de scope il est vrai que je n'ai pas pensé à ça, techniquement ça ne peut donc pas marcher (j'étais étonné de ne pas avoir pensé à ça en écrivant mon commentaire précédent, je comprends mieux maintenant).
C'était principalement mon gros point de blocage, si c'est ajouté sur la db je suis enclin à implémenter cette solution, qui comme tu le précises n'est pas simple mais semble être le meilleur moyen en l'état pour faire du E2E. Tiens moi au courant de l'issue de ta requête auprès de FC. |
Je n'ai pas attendu la réponse de FC, j'ai joué avec Playwright, ce que je voulais faire depuis un moment. https://github.com/guillett/franceconnect-public-subs
|
Stylé ! Tu penses que c'est envisageable de faire une PR sur le dépôt de FC ? Ça me permettrait d'éviter de lookup sur 2 dépôts différents. |
Ou alternative: tu le fais sur ton propre dépôt (même si c'est peu idéal pour une question de maintenabilité). Perso ça me va si je n'ai pas besoin de sourcer N fichiers (et donc avoir des incohérences de données). |
Je trouve l'expérience de développement des API France Connectées assez laborieuse.
En effet, @skelz0r disait sur Mattermost
La chance qu'on a en dev sur FC c'est que clientID et clientSecret sont publics et donc les subs sont partagé avec tout le monde.
Plutôt que de passer par le token
mesri
(oucnous
), est ce qu'il serait possible de repliquer ce qui se passe en prod en se basant sur un dictionnaire dont les clés sur lessub
de dev FC.Par exemple pour 'Angela Claire Louise DUBOIS' de FC, dont le
sub
estb6048e95bb134ec5b1d1e1fa69f287172e91722b9354d637a1bcf2ebb0fd2ef5v1
(pour le clientID/Secret public), on pourrait faire correspondre un payload donné pour les API France Connectées que vous gérez. Par exemple, pourapi-statut-etudiant
:On peut envisager un ou plusieurs fichiers yaml. Par exemple, avec un seul fichier, il pourrait ressembler à ça
Où
b6048e95bb134ec5b1d1e1fa69f287172e91722b9354d637a1bcf2ebb0fd2ef5v1
est donc lesub
.sub
récupérable par un appel à${fcRoot}/api/v1/userinfo?schema=openid
et dans le JWT du champid_token
. Par exempleet dont le contenu est
(signé avec le clientSecret d'ailleurs mais on s'en fiche un peu ici).
The text was updated successfully, but these errors were encountered: