正如消息隊列能夠讓同一個組織內的多個應用相互通信一樣， WebHooks也為來自不同組織的網站提供了一種以異步的形式進行通信的方法。

\u0026#xD;\n\u0026#xD;\n

從本質上說，WebHook就是一種回調機制。用戶可以在WebHook提供者中注冊一個自定義的URL，提供者將在適當的時機通過這個URL將相關的事件以消息的方式發送給應用。比方說，用戶可以對Dropbox進行配置，當某個公司的Dropbox帳戶中添加了一個新文件時，同時向該公司的審計與備份基礎設施發出一條通知。

\u0026#xD;\n\u0026#xD;\n

雖然從理論上說，這些功能完全有可能實現，但在現實世界中往往需要考慮到各種其他因素。如果忽視了這些因素，則惡意用戶可利用這種基礎設施發起拒絕攻擊服務，正如pingback曾經出現過的漏洞一樣。

\u0026#xD;\n\u0026#xD;\n

為了防止發生這方面的安全問題，WebHooks設計了一個驗證步驟。Dropbox的文檔中是這樣寫的：

\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n

當你輸入WebHooks URI時，就會自動向該URI發送一個初始的“驗證請求”。驗證過程使用了一個HTTP GET請求，其中帶有一個名為challenge的查詢參數。而你的應用在對該請求的響應中也需要包含這個challenge參數。這個驗證過程請求的目的是確保你的應用確實希望通過該URI獲取通知信息。即使你無意中輸入了錯誤的URI（或者有人試圖惡意地將你的服務器設置為他的WebHook），由于你的應用無法正確地響應challenge請求，因此Dropbox仍然不會向該URI發送任何通知。

\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n

接收

\u0026#xD;\n\u0026#xD;\n

在RC 1版本中，ASP.NET WebHooks包含支持以下提供商的自定義“接收者”：

\u0026#xD;\n\u0026#xD;\n

• Azure Alerts與Kudu\u0026#xD;\n\u0026#xD;\n
• BitBucket\u0026#xD;\n\u0026#xD;\n
• Microsoft Dynamics CRM\u0026#xD;\n\u0026#xD;\n
• Dropbox\u0026#xD;\n\u0026#xD;\n
• GitHub\u0026#xD;\n\u0026#xD;\n
• Instagram\u0026#xD;\n\u0026#xD;\n
• MailChimp\u0026#xD;\n\u0026#xD;\n
• PayPal\u0026#xD;\n\u0026#xD;\n
• Pusher\u0026#xD;\n\u0026#xD;\n
• Salesforce\u0026#xD;\n\u0026#xD;\n
• Slack\u0026#xD;\n\u0026#xD;\n
• Stripe\u0026#xD;\n\u0026#xD;\n
• Trello\u0026#xD;\n\u0026#xD;\n
• WordPress\u0026#xD;\n\u0026#xD;\n
• IFTTT與Zapier\u0026#xD;\n

同時，新版本還提供了一個通用的框架庫，可用于創建用戶自定義的接收者。但用戶必須將該接收者托管在公有的網站上，否則提供者將無法連接到這些接收者。

\u0026#xD;\n\u0026#xD;\n

提供

\u0026#xD;\n\u0026#xD;\n

ASP.NET還提供了一套框架，允許用戶提供自己的WebHooks，讓其他應用程序使用。這套框架包括兩個部分，一是WebHooks基礎設施本身，二是WebHooks注冊信息的存儲機制。目前可直接使用的存儲機制包括SQL Server和Azure Table Storage。

\u0026#xD;\n\u0026#xD;\n

讀者可以在.NET Web Development and Tools博客上獲取完整的教程與示例。同時可以在GitHub找到項目的源代碼，項目本身遵循Apache 2授權協議。目前的發布候選版本需要ASP.NET MVC 5和WebAPI 2的支持。

\u0026#xD;\n\u0026#xD;\n

查看英文原文：ASP.NET WebHooks RC 1

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的ASP.NET WebHooks RC 1发布的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。