网站名称怎么起,百度直播,四川省住房和城乡建设厅官网电话,如何在百度上做广告宣传概述
如果需要通过 Webhook 端口从交易伙伴处接收数据#xff0c;但该交易伙伴可能对于安全性有着较高的要求#xff0c;而不仅仅是用于验证入站 Webhook 要求的基本身份验证用户名/密码#xff0c;或者用户可能只想在入站 Webhook 消息上增加额外的安全层。
使用 Webhook…概述
如果需要通过 Webhook 端口从交易伙伴处接收数据但该交易伙伴可能对于安全性有着较高的要求而不仅仅是用于验证入站 Webhook 要求的基本身份验证用户名/密码或者用户可能只想在入站 Webhook 消息上增加额外的安全层。
使用 Webhook 端口的自定义响应功能用户实际上可以创建自己的 HTTP 签名身份验证逻辑通过使用分配给请求标头的 HMAC 签名值对入站 Webhook 请求执行一些额外的身份验证。
扩展阅读GitHub中的操作示例
脚本
以下是在知行之桥EDI系统Webhook端口的事件选项卡下的响应中编写的脚本
!-- setting the secret key value to be available globally --
arc:set attrsecret.key valuetest /!-- specifying the HMAC format, key value, algorithm, bits and output to result in HMACSHA256 --
arc:set attrencIn.format valueHMAC /
arc:set attrencIn.hmackey value[secret.key] /
arc:set attrencIn.hmacalgorithm valueSHA /
arc:set attrencIn.hmacbits value256 /
arc:set attrencIn.outformat valueHEX /
!-- setting the data that should be included in order to create the hash. this is the body of the request --
arc:set attrencIn.data[_message.body]/arc:set!-- generating signature HMAC hex digest hash --
arc:call opencEncode inencIn outencOutarc:set attrcalculated.signature valuesha256[encOut.encodeddata] /!-- comparing the signature on the request to the signature calcuated above --arc:if exp[_httpheaders.X-Hub-Signature-256 | equals([calculated.signature | tolower()])]arc:set attr_response.writeStatusSuccess!/Status/arc:setarc:set attr_response.statuscode value200 /arc:set attr_response.statusdescription valueOK /arc:elsearc:set attr_response.writeStatusThe signature provided in the request did not match the expected signature. The expected value is [calculated.signature | tolower()]/Status/arc:setarc:set attr_response.statuscode value401 /arc:set attr_response.statusdescription valueUnauthorized: Signature Mismatch /arc:throw code500 descThe signature provided in the request did not match the expected signature. The expected value is [calculated.signature | tolower()] //arc:else/arc:if
下面提供了有关与此脚本关联的部分的进一步说明但上面脚本的每个主要部分都包含一个注释概述了该脚本部分正在执行的操作。此处使用的主要 ArcScript 操作为encEncode
实现
GitHub 的 webhook 请求的工作方式是每次我的一个存储库发生推送事件时它都会向配置的 API 端点在本例中为 知行之桥EDI系统 的 Webhook 端口发送 POST 请求。这只是特定于 GitHub但这里的想法可以转移到任何其他自动化系统甚至是能够发送 REST 请求的自定义实现。
出于测试的目的密码仅设置为一个简单的测试字符串。 推送事件发生后GitHub 会向 URL 发送一个包含一些 JSON 数据的 POST。GitHub 使用 POST 的密钥和主体计算 HMAC 十六进制摘要并将其作为标头 X-Hub-Signature-256 包含在内。
此请求到达 Webhook 端口后自定义脚本实际上会使用传入请求的密钥和截获的正文生成相同的 HMAC 十六进制摘要将其与 X-Hub-Signature-256 标头中包含的内容进行比较然后根据结果创建适当的响应。
如果签名匹配则接受请求并将 200 OK 返回给 GitHub即客户端 如果签名不匹配则请求在 Webhook 端口的“输出”选项卡中显示为“错误”并在返回给客户端 GitHub 的响应中显示为 500 错误 成功的请求在知行之桥EDI系统中显示为“成功”。此外对于失败的请求可以直接在日志文件中看到 arcthrow 引发的自定义错误
[2022-11-30T19:47:57.468] [Error] The signature provided in the request did not match the expected signature. The expected value is sha25626bf09c078ddcf555a6a7cbd362c70e18e7233d0e4cfb056d2e00bc3ba8ee5e4 [2022-11-30T194757.468][错误]请求中提供的签名与预期的签名不匹配。预期值为 sha25626bf09c078ddcf555a6a7cbd362c70e18e7233d0e4cfb056d2e00bc3ba8ee5e4
用户可以根据实际需求对上述示例进行自定义的修改有关Webhook端口的响应事件的详细信息可以参考此文档。
扩展阅读Webhook端口示例EDI是什么
