Produits Entr'ouvert » Passerelle

Il manque pas la migration?

Pas fan du endpoint_get() qui permet trop facilement de changer les URL et de ne pas voir que ça cassera tout.

Il manque:

    category = _('Business Process Connectors')
    ...
    class Meta:
        verbose_name = _('API Particulier')

    @classmethod
    def is_enabled(cls):
        return True

    @classmethod
    def get_verbose_name(cls):
        return cls._meta.verbose_name

    @classmethod
    def get_icon_class(cls):
        return 'ressources'

dans le modèle pour que le connecteur soit visible dans le backoffice et un template html decrivant les endpoints.

Il manque:

De manière plus haut niveau, une description (du besoin et) de l'usage imaginé.

Up.

Pour Fred, le cas d'usage :
La ville de Lyon fait ça avec Lutèce, on l'avait vu, pour permettre le
calcul du quotient familial :
https://qf.lyon.fr/

Sur l'endpoint correspondant à impots_adresse API Particulier répond par une 404 (plateforme de test). Sur les endpoints CAF, le résultat est une erreur 500 d'API Particulier.

Frédéric Péters a écrit :

Discussion à avoir mais il semblerait qu'on ne veuille pas lever d'erreur 500 sur des situations connues.

Je ne renvoie pas d'erreur 500

J'encourage la déclaration des applications préfixées par passerelle.apps.

Ok.

Le api_particulier_detail.html devrait être nommé apiparticulier_detail.html (est-ce un changement raté récemment ou la page n'a jamais été visitée ?).

Yep pas testé, j'ai ajouté un test.

Les URL mentionnées ne fonctionnent pas parce qu'elles devraient être en /api-particulier/ et pas /api_particulier/ et qu'il faut pour ça également ajouter :

[...]

Corrigé, ça appelle encore plus d'automatisation dans la génération des pages de détail (je pense qu'en ajoutant des catégorie et des descriptions au décoration endpoint on serait bon, on a du déjà le dire ailleurs je pense).

Il est fait mention de particulier-mock.api.gouv.fr mais ce domaine ne résoud pas chez moi.

Je ne sais plus d'où je l'ai sortir, je l'ai viré.

Pour la plateforme de dev, j'ai un "connexion refusée".

Je pense que j'avais trouvé toutes ces URLs sur https://particulier.api.gouv.fr/tech/ mais ils ont fait le ménage, je vire aussi.

L'ordre test/prod/dev/mock est pour moi curieux, j'aurais plutôt imaginé prod/test/dev/mock.

Ok, j'ai mis prod/test.

Voilà sur branche pour dernière relecture, http://git.entrouvert.org/passerelle.git/log/?h=wip/14838-api-particulier.

Frédéric Péters a écrit :

Sur l'endpoint correspondant à impots_adresse API Particulier répond par une 404 (plateforme de test). Sur les endpoints CAF, le résultat est une erreur 500 d'API Particulier.

Pour impots_adresse si je mets n'importe quoi comme numéro fiscal j'ai une 400.

Oui le service de test CAF ne fonctionne pas actuellement.

Ces remarques pour dire que ?

Discussion à avoir mais il semblerait qu'on ne veuille pas lever d'erreur 500 sur des situations connues.

Je ne renvoie pas d'erreur 500

Ok j'ai du me faire avoir par l'encapsulation de leur erreur.

Pour impots_adresse si je mets n'importe quoi comme numéro fiscal j'ai une 400.

Sur la plateforme de test ?

Oui le service de test CAF ne fonctionne pas actuellement.

Ok, je ne l'avais pas deviné.

Ces remarques pour dire que ?

Que je teste, que je voulais voir l'intégration réelle avec w.c.s. pour être sûr de ne pas rater un truc flagrant.

Frédéric Péters a écrit :

Sur la plateforme de test ?

Non tu as raison 404. Tu veux que je récupère ça pour en faire une erreur particulière ?

Non tu as raison 404. Tu veux que je récupère ça pour en faire une erreur particulière ?

Non, je suis surtout inquiet par rapport à leurs plateformes :/

À ce sujet, la plateforme de test, d'après https://particulier.api.gouv.fr/tech/ , ce serait désormais plutôt :

Test | particulier-sandbox.api.gouv.fr | test-token | Oui

(hostname différent) (mais leur doc pour les exemples CAF qui ne marchent pas pointe toujours sur particulier-test)

Frédéric Péters a écrit :

Non tu as raison 404. Tu veux que je récupère ça pour en faire une erreur particulière ?

Non, je suis surtout inquiet par rapport à leurs plateformes :/

J'ai envoyé un mail pour voir à leur email de contact, demandant aussi si tout ça est bien en prod.

À ce sujet, la plateforme de test, d'après https://particulier.api.gouv.fr/tech/ , ce serait désormais plutôt :

Test | particulier-sandbox.api.gouv.fr | test-token | Oui

(hostname différent) (mais leur doc pour les exemples CAF qui ne marchent pas pointe toujours sur particulier-test)

Ok je change pour sandbox qui est celle qu'on voit dans les exemples pour les impôts qui marchent.

Branche rebasée sur master, est-ce que ce serait poussable ? Je pense que ça
pourrait être annoncé dans les notes de releases comme un module expérimental
pour inciter des villes à s'en servir.

• commits rebasés
• serializer_type retiré
• page de description automatique utilisée en majeur partie
• ordre dans INSTALLED_APPS respecté

J'ai aussi retiré les deux endpoints CAF qui ont disparu et ont été aggrégé dans l'unique restant "famille".

Je remarque à l'occasion qu'on permet de décrire le format des arguments mais pas le format retour des endpoints ça me parait vraiment manquant, ici le format des données est documenté dans les tests.

• dans le cas fiscal le numéro fiscal de la personne et un numéro d'avis d'imposition,
• dans le cas allocation familiale, le code postal et le numéro d'allocataire.

Ensuite sur une deuxième page on peut afficher les informations retournées,
typiquement l'adresse dans les deux cas ou le QF pour le cas allocation
familiale.

En première actions de workflow on devrait refaire ces appels pour stocker la donnée dans un variable de workflow.

À noter que l'adresse retourner par la CAF n'a pas du tout la même forme que celle en provenance des impôts ce qui pourrait être gênant, mais c'est comme ça.

(je regarde e1bc6338a7229e82e3afda9bb844b4cfc6295754)

ordre dans INSTALLED_APPS respecté

Et pourtant :

     'passerelle.apps.solis',
+    'passerelle.apps.api_particulier',

page de description automatique utilisée en majeur partie

Mais pourquoi pas totalement ? Les éléments de description doivent pouvoir être tirés des paramètres du connecteur, et les paramètres en …_key rester cachés.

verbose_name=_('platform')

Il y faudrait une majuscule.

+ 'description': _('requesting user'),

Dans les tests il y est mis "John Doe" mais ce n'est pas clair pour moi ce qui doit s'y trouver, le prénom/nom de la personne de qui on récupère l'info ? Ou c'est la personne à l'origine de la demande, genre pour permettre à API Particulier un semblant de log de qui fait des demandes ?

Dans la version précédente, il y avait des valeurs d'exemple passées (code_postal=13260&numero_allocataire=15), au cas où c'est quelque chose qui peut également être fait ici, suffit d'ajouter example_value au dictionnaire décrivant le paramètre.

_~~

Je remarque à l'occasion [...]

Tickets bienvenus, toujours.

Frédéric Péters a écrit :

(je regarde e1bc6338a7229e82e3afda9bb844b4cfc6295754)

Mon push s'est perdu dans l'éther, c'est le bon maintenant, j'ai vérifié.

ordre dans INSTALLED_APPS respecté

Et pourtant :

[...]

Ouaip désolé.

page de description automatique utilisée en majeur partie

Mais pourquoi pas totalement ? Les éléments de description doivent pouvoir être tirés des paramètres du connecteur, et les paramètres en …_key rester cachés.

_platform est une énumération et get_description_field() ne renvoie pas la valeur de get_display_<_field>. Je vais virer mon template ad-hoc et ouvrir un ticket là dessus.

verbose_name=_('platform')

Corrigé.

Il y faudrait une majuscule.

+ 'description': _('requesting user'),

Dans les tests il y est mis "John Doe" mais ce n'est pas clair pour moi ce qui doit s'y trouver, le prénom/nom de la personne de qui on récupère l'info ? Ou c'est la personne à l'origine de la demande, genre pour permettre à API Particulier un semblant de log de qui fait des demandes ?

Tout ça à la fois, voici ce qui est dit dans la doc:

Le citoyen ou l'agent

1. Avec Curl, il suffit de passer le header HTTP: X-User
   curl "https://particulier-sandbox.api.gouv.fr/api/impots/svair?numeroFiscal=12&referenceAvis=15" \
   -H "X-API-KEY: test-token" \
   -H "X-User: demo"

Il est aussi possible d'identifier (sans authentifier) les citoyens ou les agents ayant déclenchés un appel donné. En effet, en cas de problème ou de fraude, les fournisseurs de données doivent être en mesure de dire quels étaient les utilisateurs de l'API Particulier. C'est pourquoi il existe un header HTTP facultatif X-User qui permet d'identifier l'utilisateur : celui-ci peut être un identifiant interne du fournisseur de service.

Au passage je découvre que API particulier est devenu aussi un FD FranceConnect, je n'y comprend plus rien.

France Connect

1. Avec Curl, il suffit de passer le header HTTP: Authorization
   curl "https://particulier-sandbox.api.gouv.fr/api/impots/svair?numeroFiscal=12&referenceAvis=15" \
   -H "Authorization: Bearer <ACCESS-TOKEN>"

Il est aussi possible de s'authentifier en tant que citoyen identifié via France Connect. Api Particulier étant un Fournisseur de Données, Il est possible pour un citoyen identifié auprès de France Connect d'accèder à ses données personnelles (et uniquement celles le concernant) en suivant le protocole OpenID Connect.

C'est une bonne nouvelle parce qu'il me semble que c'est bien plus facile d'obtenir une API key sur API particulier que de s'adresse à la DGFIP.

Dans la version précédente, il y avait des valeurs d'exemple passées (code_postal=13260&numero_allocataire=15), au cas où c'est quelque chose qui peut également être fait ici, suffit d'ajouter example_value au dictionnaire décrivant le paramètre.

J'ai repris ceux de la doc, ça permet de tester directement.

Je remarque à l'occasion [...]

Tickets bienvenus, toujours.

#21774

À noter que j'ai testé localement vers la vrai instance de FC, les 3 endpoints fonctionnent (je pourrai rajouter un tel test, ça ne mange pas de pain).

self.get('impots/adress'

Il manque le e à la fin.

Dans tests/utils.py il y a déjà la fonction setup_access_rights. Il faudrait l'utiliser dans make_ressource (à renommer au passage en make_resource, en anglais)

Serghei Mihai a écrit :

Il manque le e à la fin.

C'est plutôt une erreur sur https://particulier.api.gouv.fr/tech/ qui parle bien de https://particulier.api.gouv.fr/api/impots/adress . tu as testé ? (j'avoue, pas moi)

Thomas Noël a écrit :

Serghei Mihai a écrit :

Il manque le e à la fin.

C'est plutôt une erreur sur https://particulier.api.gouv.fr/tech/ qui parle bien de https://particulier.api.gouv.fr/api/impots/adress . tu as testé ? (j'avoue, pas moi)

https://particulier-sandbox.api.gouv.fr/api/impots/adresse = 404 alors que
https://particulier-sandbox.api.gouv.fr/api/impots/adress = ip refusée

donc y'a juste une typo dans leur URL mais pas dans le code de Benjamin

Pas testé non plus, mais vu dans les tests un appel à impots/adresse.

Serghei Mihai a écrit :

Pas testé non plus, mais vu dans les tests un appel à impots/adresse.

Bah oui j'ai pas repris la typo dans nos URLs.

Ton dernier patch ne doit pas être le bon (restent des "resource") ; mais en y mergeant le diff présenté au dessus ça me semble mériter un ack.

s/ressource/resource/ dans tests/utils.py:endpoint_get et ack

Ack