Slutpunktsverifiering med CloudEvents-schema

Webhooks är ett av många sätt att ta emot händelser från Azure Event Grid. När en ny händelse är klar skickar Event Grid-tjänsten en HTTP-begäran till den konfigurerade slutpunkten med händelseinformationen i begärandetexten.

Precis som många andra tjänster som stöder webhooks kräver Event Grid att du bevisar ägarskap för din Webhook-slutpunkt innan den börjar leverera händelser till slutpunkten. Det här kravet förhindrar att en obehörig användare översvämmar slutpunkten med händelser.

Slutpunktsverifiering med CloudEvents v1.0

CloudEvents v1.0 implementerar sin egen semantik för missbruksskydd med hjälp av metoden HTTP OPTIONS . När du använder CloudEvents-schemat för utdata använder Event Grid CloudEvents v1.0-missbruksskydd i stället för event grid-valideringshändelsemekanismen.

CloudEvent v1.0 missbruksskydd

Alla system som tillåter registrering av och leverans av meddelanden till godtyckliga HTTP-slutpunkter kan potentiellt missbrukas så att någon skadligt eller oavsiktligt registrerar adressen till ett system som inte förväntar sig sådana begäranden och som registreringsparten inte har behörighet att utföra en sådan registrering för. I extrema fall kan en meddelandeinfrastruktur missbrukas för att starta överbelastningsattacker mot en godtycklig webbplats.

För att skydda avsändaren från att missbrukas på ett sådant sätt måste ett legitimt leveransmål indikera att det samtycker till att meddelanden levereras till den.

Att nå leveransavtalet realiseras med hjälp av följande valideringshandskakning. Handskakningen kan antingen köras omedelbart vid registreringen eller som en "preflight"-begäran omedelbart före en leverans.

Det är viktigt att förstå att handskakningen inte syftar till att upprätta en autentiserings- eller auktoriseringskontext. Det skyddar bara avsändaren från att bli tillsagd till en push-överföring till ett mål som inte förväntar sig trafiken. Även om den här specifikationen kräver användning av en auktoriseringsmodell räcker inte det här mandatet för att skydda godtyckliga webbplatser från oönskad trafik om den webbplatsen inte implementerar Authorization åtkomstkontroll och därför ignorerar huvudet.

Leveransmål BÖR stödja funktionen för missbruksskydd. Om ett mål inte stöder funktionen kan avsändaren välja att inte skicka till målet alls eller bara skicka med en mycket låg begärandefrekvens.

Verifieringsbegäran

Verifieringsbegäran använder metoden HTTP OPTIONS . Begäran dirigeras till den exakta resursmål-URI som registreras. Med valideringsbegäran ber avsändaren målet om behörighet att skicka meddelanden och kan deklarera en önskad begärandefrekvens (begäranden per minut). Leveransmålet svarar med en behörighetsinstruktor och den tillåtna begärandefrekvensen. Här är några av huvudfälten som ska ingå i valideringsbegäran.

WebHook-Request-Origin

Huvudet WebHook-Request-Origin MÅSTE ingå i valideringsbegäran och begär behörighet att skicka meddelanden från den här avsändaren och innehåller ett DNS-uttryck (Domain Name System) som identifierar det sändande systemet, till exempel eventemitter.example.com. Värdet är avsett att sammanfattningsvis identifiera alla avsändarinstanser som agerar för ett visst system och inte en enskild värd.

Efter handskakningen och om behörigheten har beviljats måste avsändaren använda Origin begärandehuvudet för varje leveransbegäran, med värdet som matchar värdet för det här huvudet.

Exempel:

WebHook-Request-Origin: eventemitter.example.com

Valideringssvar

Om och endast om leveransmålet tillåter leverans av händelserna måste det svara på begäran genom att inkludera huvudena WebHook-Allowed-Origin och WebHook-Allowed-Rate . Om leveransmålet väljer att bevilja behörighet genom återanrop undanhålls svarshuvudena.

Om leveransmålet inte tillåter leverans av händelserna eller inte förväntar sig leverans av händelser och ändå hanterar HTTP OPTIONS-metoden bör det befintliga svaret inte tolkas som medgivande, och därför kan handskakningen inte förlita sig på statuskoder. Om leveransmålet annars inte hanterar HTTP OPTIONS-metoden bör det svara med HTTP-statuskod 405, som om ALTERNATIV inte stöds.

OPTIONS-svaret SKA innehålla Allow rubriken som anger att POST-metoden tillåts. Andra metoder kan tillåtas för resursen, men deras funktion ligger utanför den här specifikationens omfång.

WebHook-Allowed-Origin

Huvudet WebHook-Allowed-Origin MÅSTE returneras när leveransmålet samtycker till meddelandeleverans av ursprungstjänsten. Värdet MÅSTE antingen vara det ursprungsnamn som anges i WebHook-Request-Origin rubriken eller ett singulärt asterisktecken ('*'), vilket anger att leveransmålet stöder meddelanden från alla ursprung.

WebHook-Allowed-Origin: eventemitter.example.com

Eller

WebHook-Request-Origin: *

Viktigt!

Mer information om missbruksskydd finns i Missbruksskydd i HTTP 1.1 Web Hooks för händelseleveransspecifikation.

Relaterat innehåll

I följande artikel får du lära dig hur du felsöker valideringar av händelseprenumerationer: Felsöka valideringar av händelseprenumerationer.