Verifisering av signerte webhooks
Verifiser HMAC-signerte webhooks før Shopify Flow kjøres. Velg blant 22 innebygde leverandører eller sett opp en tilpasset signatur for andre tjenester.
Mange tjenester signerer webhookene de sender, slik at mottakeren kan bekrefte at en forespørsel faktisk kom fra dem og ikke ble endret underveis. Hvis du angir HMAC som autentiseringsmetode for en webhook, sjekker appen denne signaturen før noe når Shopify Flow. En forespørsel som ikke består sjekken, avvises med 401, og arbeidsflyten utføres aldri.
Det er to måter å konfigurere dette på: Velg avsender fra listen, eller beskriv hvordan signaturen ser ut.
Innebygde leverandører
Velg leverandøren under Signaturleverandør og lim inn signeringsnøkkelen. Appen kontrollerer deretter at leverandøren følger sine egne spesifikasjoner - riktig overskrift, koding, signert innhold og replay-vindu - så det er ikke noe annet du trenger å konfigurere. Hver leverandør har sin egen veiledning for oppsett, fra opprettelse av endepunktet til å bygge opp Shopify Flow-arbeidsflyten.
Hver veiledning angir nøyaktig hva appen sjekker for den aktuelle avsenderen, og hvor man finner signeringsnøkkelen.
Egendefinert signatur: enhver annen avsender
Hvis avsenderen din ikke står på listen, velger du Egendefinert signatur og beskriver hvordan den signerer. Dokumentasjonen fra leverandøren din vil inneholde en linje som for eksempel:
X-Acme-Signature = hex(hmac_sha256(secret, timestamp + "." + body))
Den ene linjen gir svar på alle feltene:
| Innstilling | Fra eksemplet | Hva det betyr |
|---|---|---|
| Signaturhode | X-Acme-Signature |
Overskriften med signaturen |
| Algoritme | hmac_sha256 |
SHA-256, SHA-1 eller SHA-512 |
| Koding | hex |
hex, base64 eller base64url |
| Signert nyttelast | {timestamp}.{body} |
Den nøyaktige teksten som ble undertegnet |
| Tidsstempel | en overskrift som for eksempel X-Acme-Timestamp |
Hvor timestamp-verdien havner |
| Toleranse for gjentakelse | 300 sekunder | Avvis forespørsler som er eldre enn dette |
Den signerte nyttelasten
Skriv hva avsenderen signerer ved å bruke disse plassholderne:
| Plassholder | Blir |
|---|---|
{body} |
Den ubehandlede forespørselsteksten, byte for byte. Obligatorisk. |
{timestamp} |
Tidsstemplet fra overskriften eller signaturoverskriften |
{url} |
URL-adressen til denne webhooken, slik du angav den hos avsenderen |
{header:name} |
Verdien av en annen forespørselsheader |
Vanlige formater: {body}, {timestamp}.{body}, {timestamp}{body}, v0:{timestamp}:{body}, {header:webhook-id}.{timestamp}.{body}. Bruk Start fra en leverandør for å kopiere et format som ligner, og endre bare det som er annerledes.
Hvor signaturen skal plasseres
- Enkelt: Verdien i overskriften er signaturen, eventuelt etterfulgt av et prefiks du selv velger, for eksempel
sha256=ellerv1,. - Nøkkel = verdi: overskriften inneholder par som
t=1700000000,v1=abc.... Angi navnet på nøkkelen som inneholder signaturen (v1), eventuelt navnet på nøkkelen som inneholder tidsstemplet (t), og om parene er atskilt med,eller;.
Hvis en overskrift inneholder flere signaturer atskilt med mellomrom - noe enkelte avsendere gjør når man roterer en hemmelighet - godtas hvilken som helst av dem som stemmer overens.
Hemmeligheten
Vanligvis limer du inn nøkkelen slik avsenderen viser den. Noen avsendere oppgir en base64-kodet nøkkel med et prefiks, for eksempel whsec_...: Velg base64-kodet og skriv inn prefiks som skal fjernes.
Testing før oppstart
Signaturtesteren ligger under innstillingene og fungerer selv om endringene ikke er lagret.
- Lim inn brødteksten og overskriftene fra en ekte forespørsel, og trykk på Verifiser. Du får se hvert trinn - overskrift funnet, signatur lest, tidsstempel innenfor området, nyttelast opprettet, signaturer sammenlignet - samt den eksakte teksten som ble signert. På denne måten viser en uoverensstemmelse deg nøyaktig hvor feilen oppstod, i stedet for bare en melding om «ugyldig signatur».
- Funksjonen Generer et gyldig eksempel genererer korrekt signerte overskrifter og en
curl-kommando som er klar til bruk, tilpasset dine nåværende innstillinger. Hvis denne forespørselen godtas, er konfigurasjonen din konsistent fra ende til ende.
Testeren starter aldri en arbeidsflyt, skriver ikke noe til historikken og teller ikke med i abonnementet ditt.
Signaturen stemmer ikke overens. Hva bør jeg sjekke?
I denne rekkefølgen: hemmeligheten (den vanligste årsaken, for eksempel et ekstra mellomrom eller feil nøkkel for miljøet), den signerte nyttelasten (en manglende . eller : mellom tidsstempel og hoveddel), kodingen (hex vs. base64) og om noe mellom avsenderen og appen har endret hoveddelen. Signaturene dekker de rå byteene, så en proxy som omformaterer JSON ødelegger dem.
Forespørsler mislykkes med feilmeldingen «tidsstempel utenfor toleranseområdet»
Avsenderens klokke er feilinnstilt, forespørselen ble forsinket eller sendt på nytt med en gammel tidsstempel, eller tidsstempel-enheten er feil. Sjekk om avsenderen bruker sekunder, millisekunder eller en ISO-dato.
Avsenderen min må først gjennomføre en bekreftelsesprosess
Noen tjenester (Zoom, Dropbox, Asana, Trello, Notion) sender en bekreftelsesforespørsel som endepunktet må svare på før de leverer hendelser - hver på sin måte. Av den grunn tilbys de ikke som «ett-klikk»-leverandører. Kontakt kundestøtte og oppgi navnet på avsenderen din hvis du trenger en av disse tjenestene.
Er signaturen lagret et sted?
Nei. Signaturhoder blir skjult i «Historikk» og i «Live Request Inspector», fordi en signatur kan gjentas innenfor toleransevinduet.