Godkendelse

Enhver, der kender en webhook-URL, kan sende en anmodning til den, så det er autentificeringen, der forhindrer en fremmed i at udløse dine Shopify Flow-arbejdsgange. Indstil det for hver enkelt webhook under afsnittet »Sikkerhed« for den pågældende webhook.

De tre metoder

Metode	Hvordan den, der ringer, beviser sin identitet	Brug den, når
Ingen	Intet	Kun til test - må aldrig bruges i produktion
Statisk token	En fast hemmelighed i en anmodningsheader	Næsten alle integrationsmuligheder (n8n, Make, Zapier, din egen kode)
HMAC SHA-256	En signatur, der er beregnet ud fra anmodningen og en fælles hemmelighed	Afsenderen signerer sine webhooks (Stripe, GitHub, Slack, …)

Statisk token

Tryk på knappen »Generer« på webhooken for at få et stærkt tilfældigt token, eller indsæt dit eget. Den, der kalder webhooken, sender det i en header:

Webhook-editoren: navn og godkendelse til venstre, Endpoint-kortet med status, webhook-URL og webhook-ID til højre, over »Live Preview«, »Test« og »Usage« — Et statisk token: Vælg, hvordan afsenderen skal videregive det, generer eller indsæt tokenet, og kopier webhook-URL'en fra kortet »Endpoint«.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

Ændring af overskriftens navn

Nogle systemer kan kun sende en header, som de allerede bruger. Indstil navnet på Auth-headeren under »Avancerede indstillinger«, så læser vi tokenet fra den pågældende header i stedet for fra X-Api-Key:

bash

  -H "X-Custom-Auth: your-token"

Der skelnes ikke mellem store og små bogstaver i header-navne. Reserverede navne afvises - Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* og lignende. Disse indstilles eller omskrives af proxyservere og CDN’er, så et token, der læses fra en sådan, vil kunne kontrolleres af en angriber.

Hvor tokenet bevæger sig hen

Det er ikke alle afsendere, der kan tilføje en vilkårlig header. Hvordan videregiver afsenderen tokenet? Under fanen »Webhook« findes der fire muligheder:

Valg	Afsenderen sender	Brug den, når
I en brugerdefineret overskrift	`X-Api-Key: <token>` eller det navn, du vælger til overskriften	Standardindstillingen, og sådan fungerer de fleste integrationer
Som et bearer-token	`Authorization: Bearer <token>`	Værktøjet har et felt til »Bearer«- eller API-token
Som brugernavn og adgangskode	HTTP Basic, med et brugernavn, du selv vælger, og tokenet som adgangskode	Værktøjet understøtter kun Basic-autentificering
I URL’en	`?token=<token>` eller det parameternavn, du vælger	Afsenderen kan kun kalde en almindelig URL og kan ikke indstille headere

Authorization navnet på den brugerdefinerede header forbliver bevidst uændret: »Bearer« og »Basic« er de understøttede måder at bruge den på, og begge håndteres automatisk for dig. En »401« for disse to medfører også en »WWW-Authenticate«-header, da flere HTTP-klienter kun sender legitimationsoplysninger, når de bliver bedt om det.

URL-indstillingen er den svageste af de fire - URL’er ender i logfiler, henvisningskilder og browserhistorikken - så brug den kun, når afsenderen ikke giver dig noget andet valg. Appen viser den færdige URL med tokenet indsat og skjuler denne parameter overalt, hvor den gemmer anmodningen.

HMAC SHA-256

Afsenderen beregner en signatur for anmodningen ved hjælp af en fælles hemmelighed; vi beregner den på ny og sammenligner. En lækket anmodning kan ikke gentages med ændret indhold, da selve anmodningen ikke længere stemmer overens med signaturen.

Forudindstillinger for udbydere

Vælg din udbyder under »Signaturudbyder«, så verificerer vi ved hjælp af netop denne udbyders præcise skema - headernavn, kodning, hvad der underskrives, og hvor længe en signatur er gyldig. Indsæt signaturnøglen fra udbyderens kontrolpanel, og så er du færdig.

Der er 22 indbyggede udbydere, som hver har sin egen opsætningsvejledning: Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Standard Webhooks (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce og Zendesk. Hvis din udbyder ikke er på listen, skal du beskrive, hvordan den kommunikerer med et brugerdefineret skema.

Se Bekræftelse af signerede webhooks for den fulde liste, indstillingen til brugerdefinerede signaturer og den indbyggede signaturtester.

En webhook med HMAC-godkendelse og Stripe som signaturudbyder, der viser feltet »signing secret«, hvad der kontrolleres, samt trinene til at oprette forbindelse til Stripe — En signeret afsender, her Stripe: Vælg udbyderen, indsæt dennes signeringsnøgle, hvorefter redigeringsværktøjet viser, hvad der er markeret, og hvordan man forbinder det.

Generisk HMAC

Da der hverken findes en forudindstillet eller en brugerdefineret skema, bruger vi vores eget: Opkaldsmodtageren sender X-Signature, nemlig HMAC-SHA256-værdien af header-værdierne i X-Webhook-* ved hjælp af signeringsnøglen.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

Sådan ser et afslag ud

Ved mislykket godkendelse returneres 401 med en JSON-tekst, der angiver årsagen - se Historik og fejlfinding for den fulde liste over koder. Afviste anmodninger vises stadig i Live Request Inspector, mens du redigerer webhooken, så du kan se præcis, hvorfor en anmodning blev afvist.

Omskiftning af hemmeligheden uden driftsstop

Hvis man ændrer en hemmelighed i ét trin, betyder det, at alle anmodninger, der er underskrevet med den gamle hemmelighed, mislykkes, indtil afsenderen har nået at tilpasse sig. Ved at skifte den hemmelige nøgle via webhooken undgår man dette: Den indeholder en anden gyldig hemmelighed, der accepteres sideløbende med den primære, både til det statiske token og til alle signaturordninger.

Indtast den nye adgangskode i feltet »Anden gyldig adgangskode«, og gem. Begge adgangskoder accepteres nu.
Skift afsenderen over til den nye hemmelighed.
Tryk på »Promote«, hvilket flytter det over i hovedfeltet og rydder det andet felt, og gem.

Ingen anmodninger afvises på noget tidspunkt. Den anden nøgle gemmes på nøjagtig samme måde som hovednøglen og returneres aldrig af API’et - der returneres kun oplysninger om, hvorvidt der er angivet en sådan.

At bevare hemmeligheden

Tokenet returneres aldrig af vores REST API eller MCP-server på noget adgangsniveau - de Angiv kun, om der er angivet en. Se Udvikler-API og MCP.
Den er krypteret, når den er gemt.
Når du roterer den, træder ændringen i kraft med det samme, så brug hellere den anden hemmelige Shopify Flow ovenfor i stedet for overskrivning af hovedfeltet.
Den gemte opkaldshistorik skjuler autentificeringsheaderen, Basic-legitimationsoplysningerne og URL-tokenet, Så et skærmbillede af historikken afslører ikke din hemmelighed.

At indsnævre det yderligere

Autentificering beviser, at den, der ringer, kender den hemmelige kode. »IP-tilladelseslister« begrænser, hvor et opkald må komme fra, og kan kombineres med alle ovenstående tilstande.