You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/event-grid/webhook-event-delivery.md
+8-6Lines changed: 8 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,10 @@ Webhooks are one of the many ways to receive events from Azure Event Grid. When
11
11
12
12
Like many other services that support webhooks, Event Grid requires you to prove ownership of your Webhook endpoint before it starts delivering events to that endpoint. This requirement prevents a malicious user from flooding your endpoint with events.
13
13
14
+
15
+
## Endpoint validation with CloudEvents v1.0
16
+
CloudEvents v1.0 implements its own abuse protection semantics using the **HTTP OPTIONS** method. You can read more about it [here](https://github.com/cloudevents/spec/blob/v1.0/http-webhook.md#4-abuse-protection). When you use the CloudEvents schema for output, Event Grid uses the CloudEvents v1.0 abuse protection in place of the Event Grid validation event mechanism.
17
+
14
18
## Endpoint validation with Event Grid events
15
19
When you use any of the following three Azure services, the Azure infrastructure automatically handles this validation:
16
20
@@ -22,7 +26,7 @@ If you're using any other type of endpoint, such as an HTTP trigger based Azure
22
26
23
27
-**Synchronous handshake**: At the time of event subscription creation, Event Grid sends a subscription validation event to your endpoint. The schema of this event is similar to any other Event Grid event. The data portion of this event includes a `validationCode` property. Your application verifies that the validation request is for an expected event subscription, and returns the validation code in the response synchronously. This handshake mechanism is supported in all Event Grid versions.
24
28
25
-
-**Asynchronous handshake**: In certain cases, you can't return the `validationCode` in response synchronously. For example, if you use a third-party service (like [`Zapier`](https://zapier.com) or [IFTTT](https://ifttt.com/)), you can't programmatically respond with the validation code.
29
+
-**Asynchronous handshake**: In certain cases, you can't return the `validationCode` in response synchronously. For example, if you use a non-Microsoft service (like [`Zapier`](https://zapier.com) or [IFTTT](https://ifttt.com/)), you can't programmatically respond with the validation code.
26
30
27
31
Event Grid supports a manual validation handshake. If you're creating an event subscription with an SDK or tool that uses API version 2018-05-01-preview or later, Event Grid sends a `validationUrl` property in the data portion of the subscription validation event. To complete the handshake, find that URL in the event data and do a GET request to it. You can use either a REST client or your web browser.
28
32
@@ -42,7 +46,7 @@ If you're using any other type of endpoint, such as an HTTP trigger based Azure
42
46
- The `data` property of the event includes a `validationCode` property with a randomly generated string. For example, `validationCode: acb13…`.
43
47
- The event data also includes a `validationUrl` property with a URL for manually validating the subscription.
44
48
- The array contains only the validation event. Other events are sent in a separate request after you echo back the validation code.
45
-
- The EventGrid data plane SDKs have classes corresponding to the subscription validation event data and subscription validation response.
49
+
- The Event Grid data plane SDKs have classes corresponding to the subscription validation event data and subscription validation response.
46
50
47
51
An example SubscriptionValidationEvent is shown in the following example:
48
52
@@ -74,7 +78,7 @@ To prove endpoint ownership, echo back the validation code in the `validationRes
74
78
75
79
And, follow one of these steps:
76
80
77
-
- You must return an **HTTP 200 OK** response status code. **HTTP 202 Accepted** isn't recognized as a valid Event Grid subscription validation response. The HTTP request must complete within 30 seconds. If the operation doesn't finish within 30 seconds, then the operation will be canceled and it may be reattempted after 5 seconds. If all the attempts fail, then it's treated as validation handshake error.
81
+
- You must return an **HTTP 200 OK** response status code. **HTTP 202 Accepted** isn't recognized as a valid Event Grid subscription validation response. The HTTP request must complete within 30 seconds. If the operation doesn't finish within 30 seconds, then the operation will be canceled and it's reattempted after 5 seconds. If all the attempts fail, then it's treated as validation handshake error.
78
82
79
83
The fact that your application is prepared to handle and return the validation code indicates that you created the event subscription and expected to receive the event. Imagine the scenario that there's no handshake validation supported and a hacker gets to know your application URL. The hacker can create a topic and an event subscription with your application's URL, and start conducting a DoS attack to your application by sending a lot of events. The handshake validation prevents that to happen.
80
84
@@ -87,9 +91,6 @@ And, follow one of these steps:
87
91
88
92
For an example of handling the subscription validation handshake, see a [C# sample](https://github.com/Azure-Samples/event-grid-dotnet-publish-consume-events/blob/master/EventGridConsumer/EventGridConsumer/Function1.cs).
89
93
90
-
## Endpoint validation with CloudEvents v1.0
91
-
CloudEvents v1.0 implements its own abuse protection semantics using the **HTTP OPTIONS** method. You can read more about it [here](https://github.com/cloudevents/spec/blob/v1.0/http-webhook.md#4-abuse-protection). When you use the CloudEvents schema for output, Event Grid uses the CloudEvents v1.0 abuse protection in place of the Event Grid validation event mechanism.
92
-
93
94
## Event schema compatibility
94
95
When a topic is created, an incoming event schema is defined. And, when a subscription is created, an outgoing event schema is defined. The following table shows you the compatibility allowed when creating a subscription.
95
96
@@ -105,5 +106,6 @@ When a topic is created, an incoming event schema is defined. And, when a subscr
105
106
|| Cloud Events v1.0 schema | Yes |
106
107
|| Custom input schema | Yes |
107
108
109
+
108
110
## Next steps
109
111
See the following article to learn how to troubleshoot event subscription validations: [Troubleshoot event subscription validations](troubleshoot-subscription-validation.md).
0 commit comments