Aller au contenu

Tester les webhooks

Trois niveaux, du test unitaire jusqu'à la relance d'une livraison live.

Un handler de webhook possède trois modes d'échec à tester séparément : il accepte un élément qu'il devrait refuser, refuse un élément qu'il devrait accepter ou effectue deux fois le même travail. Chacun est détecté à un niveau différent.

NiveauProblème détectéPrérequis
Test unitaireUn vérificateur qui accepte une signature falsifiéeAucun, il s'agit d'un calcul pur
La CLIUn handler qui plante sur un véritable payloadwajub listen et wajub trigger
KonsoleUn endpoint réellement inaccessible depuis votre serveurUn endpoint enregistré

Niveau 1 : signer vous-même un payload

La signature utilise HMAC-SHA256 sur "{timestamp}.{body}". Un test peut donc en produire une valide sans aucun accès réseau. Écrivez les quatre cas : signature valide, mauvais secret, corps altéré et ancien horodatage.

# The string that gets signed, for reference
TIMESTAMP=1748083260
BODY='{"id":"evt_test_1","event":"payment.succeeded","data":{}}'

printf '%s.%s' "$TIMESTAMP" "$BODY" \
| openssl dgst -sha256 -hmac "whsec_test_secret" -r \
| cut -d' ' -f1

Niveau 2 : un événement réel sur votre machine

Les tests unitaires vérifient le vérificateur. Ils ne prouvent pas que le handler résiste à un véritable payload, avec des champs inattendus et des types que vous n'aviez pas prévus.

Deux terminaux
# 1
wajub listen --forward-to localhost:3000/webhooks/wajub

# 2
wajub trigger payment.succeeded
wajub trigger payment.failed
wajub trigger refund.succeeded

La CLI signe les éléments qu'elle transfère avec un secret qu'elle affiche. Votre vérification s'exécute donc réellement. Exportez ce secret. Rien d'autre ne change dans votre code.

Le déclenchement de payment.succeeded livre à lui seul cinq événements. Si votre handler n'en connaît qu'un, les quatre autres arrivent actuellement dans sa branche par défaut.

Niveau 3 : l'endpoint déployé

Deux boutons distincts dans Konsole répondent à deux questions différentes.

BoutonVérification effectuée
Send testWajub peut atteindre votre URL et la vérification de signature réussit
Retry a deliveryVotre handler traite maintenant un véritable événement qui avait auparavant échoué

Les quatre vérifications utiles

Ces quatre vérifications s'exécutent au niveau 1, dans votre propre suite et sans réseau. Chacune précise l'entrée qui produit la condition. Aucune ne nécessite donc une livraison réelle pour reproduire le résultat.

VérificationMéthodeCondition de réussite
Une signature falsifiée est rejetéeUn mauvais secret, un octet modifié dans le corps ou l'absence complète de X-Wajub-SignatureVotre endpoint répond avec un code 4xx et n'écrit rien
Une livraison rejouée est rejetéeUne signature valide sur un horodatage vieux de 400 secondesVotre endpoint répond avec un code 4xx, car la fenêtre complète est de 300 secondes
Deux livraisons du même événement n'effectuent le travail qu'une foisLe même corps et les mêmes en-têtes, envoyés une deuxième foisUne commande, un e-mail et un crédit
Un handler occupé répond toujours à tempsVotre handler alors que la file d'attente est déjà pleineLa réponse part en moins de 10 secondes, car une réponse plus lente déclenche une nouvelle tentative

La première est votre seule protection entre le code de livraison de vos commandes et toute personne qui découvre votre URL. L'absence de la troisième vous coûte de l'argent, car chaque livraison est tentée jusqu'à cinq fois.

Que pensez-vous de ce contenu ?