正如消息队列能够让同一个组织内的多个应用相互通信一样, WebHooks 也为来自不同组织的网站提供了一种以异步的形式进行通信的方法。
从本质上说,WebHook 就是一种回调机制。用户可以在 WebHook 提供者中注册一个自定义的 URL,提供者将在适当的时机通过这个 URL 将相关的事件以消息的方式发送给应用。比方说,用户可以对 Dropbox 进行配置,当某个公司的 Dropbox 帐户中添加了一个新文件时,同时向该公司的审计与备份基础设施发出一条通知。
虽然从理论上说,这些功能完全有可能实现,但在现实世界中往往需要考虑到各种其他因素。如果忽视了这些因素,则恶意用户可利用这种基础设施发起拒绝攻击服务,正如 pingback 曾经出现过的漏洞一样。
为了防止发生这方面的安全问题,WebHooks 设计了一个验证步骤。 Dropbox 的文档中是这样写的:
当你输入 WebHooks URI 时,就会自动向该 URI 发送一个初始的“验证请求”。验证过程使用了一个 HTTP GET 请求,其中带有一个名为 challenge 的查询参数。而你的应用在对该请求的响应中也需要包含这个 challenge 参数。这个验证过程请求的目的是确保你的应用确实希望通过该 URI 获取通知信息。即使你无意中输入了错误的 URI(或者有人试图恶意地将你的服务器设置为他的 WebHook),由于你的应用无法正确地响应 challenge 请求,因此 Dropbox 仍然不会向该 URI 发送任何通知。
接收
在 RC 1 版本中,ASP.NET WebHooks 包含支持以下提供商的自定义“接收者”:
- Azure Alerts 与 Kudu
- BitBucket
- Microsoft Dynamics CRM
- Dropbox
- GitHub
- MailChimp
- PayPal
- Pusher
- Salesforce
- Slack
- Stripe
- Trello
- WordPress
- IFTTT 与 Zapier
同时,新版本还提供了一个通用的框架库,可用于创建用户自定义的接收者。但用户必须将该接收者托管在公有的网站上,否则提供者将无法连接到这些接收者。
提供
ASP.NET 还提供了一套框架,允许用户提供自己的 WebHooks,让其他应用程序使用。这套框架包括两个部分,一是 WebHooks 基础设施本身,二是 WebHooks 注册信息的存储机制。目前可直接使用的存储机制包括 SQL Server 和 Azure Table Storage。
读者可以在.NET Web Development and Tools 博客上获取完整的教程与示例。同时可以在GitHub 找到项目的源代码,项目本身遵循 Apache 2 授权协议。目前的发布候选版本需要 ASP.NET MVC 5 和 WebAPI 2 的支持。
查看英文原文: ASP.NET WebHooks RC 1
评论