IP白名单
身份验证可证明_调用者_知晓您的密钥。IP 白名单会限制调用可能来自的来源,因此仅凭泄露的令牌还不足以发起调用。请在“高级设置”->“IP 白名单”下为每个 Webhook 分别设置。
它会在 Webhook 使用的任何身份验证机制之上生效,包括**“None**”情况。来自任何其他地址的请求都会被拒绝,并返回状态码403以及原因ip_not_allowed,甚至在检查令牌或签名之前就会被拒绝。
填写清单
每行一个条目,最多50条:
- 一个 IPv4 或 IPv6 地址,例如
203.0.113.10或2001:db8::1 - 一个 CIDR 范围,例如
203.0.113.0/24或2001:db8::/32
大多数值得列入白名单的发件方都会公开其外发IP范围 - - Stripe、GitHub、Shopify和Square都是如此。将这些范围添加到白名单中,并在发件方宣布变更时重新核对:一个从未更新的白名单最终会导致误拒正常流量。
它会检查哪些请求
| 请求 | 白名单生效 |
|---|---|
| 对 Webhook URL 的调用 | 是的 |
| 对应用代理 URL 的调用 | 不 - - 这些邮件是从 Shopify 的服务器发来的,而不是来自您的发件人 |
| 计划运行 | 不 - - 我们自己提出请求 |
| 调用此 Webhook 的 Shopify Flow 操作 | 不 |
| 发送“历史记录”中的测试和回放 | 不 |
正因如此,白名单无法替代身份验证:通往 Webhook 的若干合法路径并不经过白名单。
我们要比较的地址
我们会将请求实际发自的地址作为比对依据。如果发件人与我们之间存在任何中间环节 - - 例如企业代理、API 网关、隧道或 CDN - - 那么您需要将其加入白名单的应是该中间环节的地址,而非源服务器的地址。
查找它的最快方法是:发送一个允许列表为空的请求,在 历史与故障排除 中打开该条目,然后查看我们记录的地址。
当事情出错时
被拒绝的请求仍会显示在“历史记录”中,并附有 403 和 ip_not_allowed,因此您可以查看被拒绝的地址并将其添加进去。没有任何请求会被静默丢弃。
相关
- 身份验证 - 令牌、持有人、基本参数和查询参数。
- 验证已签名的 Webhook - 对进行签名的发件人进行 HMAC 验证。
- 历史与故障排除 - 每个请求,无论是否被接受。

