test du proxy

teddy.morel commented

2026-07-02 12:58:17 +02:00

Owner

proxy en mod test:
https://pp.esalink.pdplibre.org/
issue pour échanger

proxy en mod test: https://pp.esalink.pdplibre.org/ issue pour échanger

bruno.d2b commented

2026-07-20 16:34:54 +02:00

Member

Je ne créé pas de ticket à part, mais je souhaiterais utiliser l'instance de preprod pour mes tests avec Factur-e. J'ai fait l'analyse des deux branches n7w (le code et la doc de Camille) avec Claude.
Pour avancer, il faudrait charger mon client id (distributeur).

Titre : [Proxy EsaLink] Seeder le distributeur Factur-e (mode proxy)

Instance : proxy pp (https://pp.esalink.pdplibre.org/ — à confirmer), connectée à EsaLink PPD (https://ppd.hubtimize.fr/api/orchestrator).

Demande : allow-lister le client_id distributeur de Factur-e, en mode proxy, sans secret stocké (Factur-e envoie son secret à chaque appel).

Commandes à exécuter (compte superadmin) :

n7w cli tenant add --tenant facture-e --name "Factur-e (distributeur EsaLink)"
n7w cli creds add  --tenant facture-e --vendor esalink --client-id bded8e0a-903f-46a3-87ce-98e98ce15ef7

Forme conteneur (depuis podman/proxy_mode/) :

podman-compose --profile cli run --rm n7w-cli tenant add --tenant facture-e --name "Factur-e (distributeur EsaLink)"
podman-compose --profile cli run --rm n7w-cli creds add  --tenant facture-e --vendor esalink --client-id bded8e0a-903f-46a3-87ce-98e98ce15ef7

Vérifications demandées à l'opérateur :

Confirmer l'URL publique exacte du proxy + le Host attendu (routage vendor par en-tête Host).
Confirmer qu'aucun credential EsaLink n'existe déjà avec ce client_id (éviter un doublon ambigu).
Confirmer que la hubtimize-api-key PPD (clé de test commune a3e49892-260f-4a3f-b497-3c9b68ee85d1) est configurée côté router (N7W_VENDOR__ESALINK__API_KEY).
Retour attendu : Tenant created: id=facture-e … puis Credential created: id=… vendor=esalink.

Test de bout en bout (après seed), côté Factur-e :

curl -X POST https://pp.esalink.pdplibre.org/token \
  -H 'Content-Type: application/json' \
  -d '{"username":"bded8e0a-903f-46a3-87ce-98e98ce15ef7","password":"<secret_distributeur>"}'
# → { "access_token": "..." } puis appels /v1/... en Authorization: Bearer

Je ne créé pas de ticket à part, mais je souhaiterais utiliser l'instance de preprod pour mes tests avec Factur-e. J'ai fait l'analyse des deux branches n7w (le code et la doc de Camille) avec Claude. Pour avancer, il faudrait charger mon client id (distributeur). **Titre :** [Proxy EsaLink] Seeder le distributeur Factur-e (mode proxy) **Instance :** proxy `pp` (`https://pp.esalink.pdplibre.org/` — à confirmer), connectée à EsaLink **PPD** (`https://ppd.hubtimize.fr/api/orchestrator`). **Demande :** allow-lister le `client_id` distributeur de Factur-e, en **mode proxy**, **sans secret stocké** (Factur-e envoie son secret à chaque appel). **Commandes à exécuter (compte superadmin) :** ``` n7w cli tenant add --tenant facture-e --name "Factur-e (distributeur EsaLink)" n7w cli creds add --tenant facture-e --vendor esalink --client-id bded8e0a-903f-46a3-87ce-98e98ce15ef7 ``` Forme conteneur (depuis `podman/proxy_mode/`) : ``` podman-compose --profile cli run --rm n7w-cli tenant add --tenant facture-e --name "Factur-e (distributeur EsaLink)" podman-compose --profile cli run --rm n7w-cli creds add --tenant facture-e --vendor esalink --client-id bded8e0a-903f-46a3-87ce-98e98ce15ef7 ``` **Vérifications demandées à l'opérateur :** - Confirmer l'URL publique exacte du proxy + le `Host` attendu (routage vendor par en-tête `Host`). - Confirmer qu'**aucun** credential EsaLink n'existe déjà avec ce `client_id` (éviter un doublon ambigu). - Confirmer que la `hubtimize-api-key` **PPD** (clé de test commune `a3e49892-260f-4a3f-b497-3c9b68ee85d1`) est configurée côté router (`N7W_VENDOR__ESALINK__API_KEY`). - Retour attendu : `Tenant created: id=facture-e …` puis `Credential created: id=… vendor=esalink`. **Test de bout en bout (après seed), côté Factur-e :** ``` curl -X POST https://pp.esalink.pdplibre.org/token \ -H 'Content-Type: application/json' \ -d '{"username":"bded8e0a-903f-46a3-87ce-98e98ce15ef7","password":"<secret_distributeur>"}' # → { "access_token": "..." } puis appels /v1/... en Authorization: Bearer ```

xt0ph commented

2026-07-21 09:23:44 +02:00

Member

Je viens d'ajouter ton accès, tu devrais pouvoir tester.

bruno.d2b commented

2026-07-23 16:41:59 +02:00

Member

Ok résultat des tests, le proxy ne voit que le client distributeur EsaLink qui permet d'accéder à EsaLink.
Mais pour discriminer les flux de plusieurs clients (Factur-e = SaaS), il faut utiliser les identifications de chaque client. Or elles ne sont pas connues du proxy.
Donc ca marche si distributeur = client, mais pour distributeur = {client} si on fait porter par le token distributeur mais on n'est pas conforme avec les consignes EsaLink (le distributeur va voir toutes les factures de ses clients...)

Faudrait-il un endpoint de provisionning équivalent à

n7w cli creds add \
  --tenant <la_societe> \
  --client-id <votre_username/client_id> \
  --vendor=<vendor>  # Par exemple esalink

Mais cela veut dire que le proxy doit connaitre tous les clients ?

Je joins la prose de Claude (pas celle de Claudel :) )

Je serai la jeudi mais si vous avez des précisions je rejoue les tests avant.

Maii peut etre que j'ai loupé quelque chose, vous parlez de username et pwd, ce sont les credentiel qu'on met dans l'IHM ? Mais ce sont des identifiants IHM, qui ne peuvent pas être utilisés pour les appel en API (j'ai vérifié).

@xt0ph @teddy.morel

Ok résultat des tests, le proxy ne voit que le client distributeur EsaLink qui permet d'accéder à EsaLink. Mais pour discriminer les flux de plusieurs clients (Factur-e = SaaS), il faut utiliser les identifications de chaque client. Or elles ne sont pas connues du proxy. Donc ca marche si distributeur = client, mais pour distributeur = {client} si on fait porter par le token distributeur mais on n'est pas conforme avec les consignes EsaLink (le distributeur va voir toutes les factures de ses clients...) Faudrait-il un endpoint de provisionning équivalent à ``` n7w cli creds add \ --tenant <la_societe> \ --client-id <votre_username/client_id> \ --vendor=<vendor> # Par exemple esalink ``` Mais cela veut dire que le proxy doit connaitre tous les clients ? Je joins la prose de Claude (pas celle de Claudel :) ) Je serai la jeudi mais si vous avez des précisions je rejoue les tests avant. Maii peut etre que j'ai loupé quelque chose, vous parlez de username et pwd, ce sont les credentiel qu'on met dans l'IHM ? Mais ce sont des identifiants IHM, qui ne peuvent pas être utilisés pour les appel en API (j'ai vérifié). @xt0ph @teddy.morel

flux-esalink-testes-pas-a-pas.md

11 KiB

xt0ph commented

2026-07-23 17:21:16 +02:00

Member

Si j'ai bien compris le besoin de base qui était de pouvoir compter et contrôler (dans le sens s'assurer que le client qui utilise le proxy est valide avec le minimum d'info stockée) l'utilisation du proxy, j'ai pensé qu'utiliser le client_id était une façon élégante de le faire.
Alors effectivement pour faire ça il faut que le proxy connaisse les client_id de tout le monde :-)

Il est possible aussi d'ajouter la notion d'utilisateur, sur lequel faire porter le client_id qui nous ajouterait la couche nécessaire au fonctionnement en mode SaaS

Tenant = ditritbuteur
    -   user1 = son client
        -  client_id = le client_id de user1 :-)
    -  user2 = son autre client
        - client_id = le client_id de user2 :-)

mais cela ne change pas le le proxy doit connaître tous les client_id.

PS : ce dernier mode je ne l'ai pas tester (encore) avec les dernière modifications du code.

Si j'ai bien compris le besoin de base qui était de pouvoir compter et contrôler (dans le sens s'assurer que le client qui utilise le proxy est valide avec le minimum d'info stockée) l'utilisation du proxy, j'ai pensé qu'utiliser le client_id était une façon élégante de le faire. Alors effectivement pour faire ça il faut que le proxy connaisse les client_id de tout le monde :-) Il est possible aussi d'ajouter la notion d'utilisateur, sur lequel faire porter le client_id qui nous ajouterait la couche nécessaire au fonctionnement en mode SaaS ``` Tenant = ditritbuteur - user1 = son client - client_id = le client_id de user1 :-) - user2 = son autre client - client_id = le client_id de user2 :-) ``` mais cela ne change pas le le proxy doit connaître tous les client_id. PS : ce dernier mode je ne l'ai pas tester (encore) avec les dernière modifications du code.

bruno.d2b commented

2026-07-23 18:45:32 +02:00

Member

L'ambiguité est dans le client :
Client distributeur = adhérent distributeur PDPLibre -> On veut compter les factures et vérifier qu'il est légitime
Clients du client distributeur = porte l'authent par un identifiant technique API de EsaLink -> utiliser pour isoler les requêtes entre clients du distributeur
On veut donc utiliser le même objet credentials pour deux usages différents.

IMO : il faut garder une identification du distributeur disjoint de l'authent de EsaLink (et de celle bientot de SuperPDP)

On en revient au sujet du trackingId décrit dans la norme XP Z12-013

5.2.2 ‘trackingId’ [Champ optionnel]
Le Fournisseur API doit accepter un ‘trackingId’ et le stocker.
Ce paramètre doit être optionnel pour le Client API.
Il permet à ce dernier de retrouver plus facilement le flux avec son propre identifiant interne.
Le Fournisseur API ne doit pas contrôler l’unicité de cet identifiant qui est un identifiant interne au Client API.

On pourrait tester si EsaLink accepte ce champ (il doit le faire selon la norme), du coup on aurait un tracking Id vérifié par le proxy qui fait la collecte des flow.
Avec une valeur par distributeur. Pas très sécurisé car un distributeur peut prendre une la valeur d'un autre distributeur. Mais c'est auditable, si le proxy trace le couple {trakingId, client-Id}, çà va se voir ! un client-id qui apparait avec deux valeurs de trackingId, c'est louche, sauf si il a deux logiciels différents pour sa facturation électronique.

A suivre

L'ambiguité est dans le client : Client distributeur = adhérent distributeur PDPLibre -> On veut compter les factures et vérifier qu'il est légitime Clients du client distributeur = porte l'authent par un identifiant technique API de EsaLink -> utiliser pour isoler les requêtes entre clients du distributeur On veut donc utiliser le même objet credentials pour deux usages différents. IMO : il faut garder une identification du distributeur disjoint de l'authent de EsaLink (et de celle bientot de SuperPDP) On en revient au sujet du trackingId décrit dans la norme XP Z12-013 ``` 5.2.2 ‘trackingId’ [Champ optionnel] Le Fournisseur API doit accepter un ‘trackingId’ et le stocker. Ce paramètre doit être optionnel pour le Client API. Il permet à ce dernier de retrouver plus facilement le flux avec son propre identifiant interne. Le Fournisseur API ne doit pas contrôler l’unicité de cet identifiant qui est un identifiant interne au Client API. ``` On pourrait tester si EsaLink accepte ce champ (il doit le faire selon la norme), du coup on aurait un tracking Id vérifié par le proxy qui fait la collecte des flow. Avec une valeur par distributeur. Pas très sécurisé car un distributeur peut prendre une la valeur d'un autre distributeur. Mais c'est auditable, si le proxy trace le couple {trakingId, client-Id}, çà va se voir ! un client-id qui apparait avec deux valeurs de trackingId, c'est louche, sauf si il a deux logiciels différents pour sa facturation électronique. A suivre

Rows
Columns

test du proxy #47