使用 CloudEvents 結構描述進行端點驗證
Webhook 是從 Azure 事件方格接收事件的眾多方法之一。 當新事件準備就緒時，「事件方格」服務就會透過 POST 對所設定的端點發佈 HTTP 要求，並在要求本文內夾帶該事件資訊。
和許多其他支援 Webhook 的服務一樣，「事件方格」也會先要求您證明具有 Webhook 端點的「擁有權」，然後才開始將事件傳遞給該端點。 此需求可避免惡意使用者利用事件癱瘓您的端點。
使用 CloudEvents v1.0 進行端點驗證
CloudEvents v1.0 會使用 HTTP OPTIONS 方法，實作其本身的濫用保護語意。 使用 CloudEvents 結構描述進行輸出時，事件方格會使用 CloudEvents v1.0 濫用保護來取代事件方格驗證事件機制。
CloudEvent v1.0 濫用保護
任何允許向任意 HTTP 端點註冊和傳遞通知的系統都有可能被濫用，以至於有人惡意或無意地註冊了未預期此類要求的系統之位址，而註冊方無權執行此類註冊。 在極端情况下，通知基礎結構可能遭濫用，對任意網站啟動拒絕服務的攻擊。
為了保護寄件者免受這種濫用，合法的傳遞目標需要表示其同意向其傳遞通知。
透過以下驗證交握實現傳遞合約的達成。 交握可以在註冊時立即執行，也可以在傳遞前立即作為「預驗」要求執行。
重要的是要了解交握的目的不是建立驗證或授權内容。 它只是用來保護寄件者不被告知推送至未預期流量的目的地。 雖然此規格授權使用授權模型，但如果任何網站沒有實作存取控制，因此略過了 Authorization 標頭，那麼這一授權不足以保護該網站免受垃圾流量的影響。
傳遞目標「應」支援濫用保護功能。 如果目標不支援功能，寄件者「可以」選擇根本不向目標傳送，或者只以非常低的要求速率傳送。
驗證要求
驗證要求使用 [HTTP OPTIONS] 方法。 要求已導向至正在註冊的確切資源目標 URI。 透過驗證要求，寄件者向目標要求傳送通知的權限，它可以宣告所需的要求速率 (每分鐘要求數)。 傳遞目標將以權限陳述式和允許的要求速率進行回應。 這裡有幾個標頭欄位要包含在驗證要求中。
WebHook-Request-Origin
WebHook-Request-Origin 標頭「必須」包含在驗證要求中，並要求允許從此寄件者發送通知，並且包含識別傳送系統的網域名稱系統 (DNS) 運算式，例如 eventemitter.example.com。 值旨在概括地識別代表某個系統而非個別主機動作的所有寄件者執行個體。
交握後，如果授與了權限，寄件者「必須」為每個傳遞要求使用 Origin 要求標頭，其值與此標頭的值相符。
範例：
WebHook-Request-Origin: eventemitter.example.com
驗證回應
如果且只有在傳遞目標允許傳遞事件時，其「必須」包含 WebHook-Allowed-Origin 和 WebHook-Allowed-Rate 標頭來回覆要求。 如果傳遞目標選擇透過回撥來授與權限，它將保留回應標頭。
如果傳遞目標不允許傳遞事件或未預期傳遞事件，但仍處理 HTTP OPTIONS 方法，則不應將現有回應解釋為同意，因此交握不能依賴於狀態代碼。 如果傳遞目標不處理 HTTP OPTIONS 方法，則「應」傳回 HTTP 狀態代碼 405，就像不支援 OPTIONS 一樣。
OPTIONS 回應「應」包括指示允許 POST 方法的 Allow 標頭。 資源上「可能」允許使用其他方法，但它們的功能不在本規格的範圍內。
WebHook-Allowed-Origin
當傳遞目標同意原點服務的通知傳遞時，「必須」傳回 WebHook-Allowed-Origin 標頭。 它的值「必須」是 WebHook-Request-Origin 標頭中提供的原點名稱，或者是單數星號字元 ('*')，表示傳遞目標支援來自所有原點的通知。
WebHook-Allowed-Origin: eventemitter.example.com
Or
WebHook-Request-Origin: *
相關內容
請參閱下列文章，了解如何針對事件訂用帳戶驗證進行疑難排解：針對事件訂用帳戶驗證進行疑難排解。