Webhook端口中的自定义签名身份认证

这篇具有很好参考价值的文章主要介绍了Webhook端口中的自定义签名身份认证。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

概述

如果需要通过 Webhook 端口从交易伙伴处接收数据,但该交易伙伴可能对于安全性有着较高的要求,而不仅仅是用于验证入站 Webhook 要求的基本身份验证用户名/密码,或者用户可能只想在入站 Webhook 消息上增加额外的安全层。

使用 Webhook 端口的自定义响应功能,用户实际上可以创建自己的 HTTP 签名身份验证逻辑,通过使用分配给请求标头的 HMAC 签名值,对入站 Webhook 请求执行一些额外的身份验证。

扩展阅读:GitHub中的操作示例

脚本

以下是在知行之桥EDI系统Webhook端口的事件选项卡下的响应中编写的脚本:

<!-- setting the secret key value to be available globally -->
<arc:set attr="secret.key" value="test" />
 
<!-- specifying the HMAC format, key value, algorithm, bits and output to result in HMACSHA256 -->
<arc:set attr="encIn.format" value="HMAC" />
<arc:set attr="encIn.hmackey" value="[secret.key]" />
<arc:set attr="encIn.hmacalgorithm" value="SHA" />
<arc:set attr="encIn.hmacbits" value="256" />
<arc:set attr="encIn.outformat" value="HEX" />
<!-- setting the data that should be included in order to create the hash. this is the body of the request -->
<arc:set attr="encIn.data">[_message.body]</arc:set>
 
<!-- generating signature HMAC hex digest hash -->
<arc:call op="encEncode" in="encIn" out="encOut">
  <arc:set attr="calculated.signature" value="sha256=[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.write"><Status>Success!</Status></arc:set>
    <arc:set attr="_response.statuscode" value="200" />
    <arc:set attr="_response.statusdescription" value="OK" />
    <arc:else>
      <arc:set attr="_response.write"><Status>The signature provided in the request did not match the expected signature. The expected value is [calculated.signature | tolower()]</Status></arc:set>
      <arc:set attr="_response.statuscode" value="401" />
      <arc:set attr="_response.statusdescription" value="Unauthorized: Signature Mismatch" />
      <arc:throw code="500" desc="The 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 请求的自定义实现。

出于测试的目的,密码仅设置为一个简单的测试字符串。

Webhook端口中的自定义签名身份认证,系统对接方式,知行edi,EDI电子数据交换 | 知行软件,EDI,电子数据交换,Webhook

推送事件发生后,GitHub 会向 URL 发送一个包含一些 JSON 数据的 POST。GitHub 使用 POST 的密钥和主体计算 HMAC 十六进制摘要,并将其作为标头 (X-Hub-Signature-256) 包含在内。

此请求到达 Webhook 端口后,自定义脚本实际上会使用传入请求的密钥和截获的正文生成相同的 HMAC 十六进制摘要,将其与 X-Hub-Signature-256 标头中包含的内容进行比较,然后根据结果创建适当的响应。

如果签名匹配,则接受请求,并将 200 OK 返回给 GitHub(即客户端):

Webhook端口中的自定义签名身份认证,系统对接方式,知行edi,EDI电子数据交换 | 知行软件,EDI,电子数据交换,Webhook

如果签名不匹配,则请求在 Webhook 端口的“输出”选项卡中显示为“错误”,并在返回给客户端 (GitHub) 的响应中显示为 500 错误:

Webhook端口中的自定义签名身份认证,系统对接方式,知行edi,EDI电子数据交换 | 知行软件,EDI,电子数据交换,Webhook

成功的请求在知行之桥EDI系统中显示为“成功”。此外,对于失败的请求,可以直接在日志文件中看到 arc:throw 引发的自定义错误:

[2022-11-30T19:47:57.468] [Error] The signature provided in the request did not match the expected signature. The expected value is sha256=26bf09c078ddcf555a6a7cbd362c70e18e7233d0e4cfb056d2e00bc3ba8ee5e4
[2022-11-30T19:47:57.468][错误]请求中提供的签名与预期的签名不匹配。预期值为 sha256=26bf09c078ddcf555a6a7cbd362c70e18e7233d0e4cfb056d2e00bc3ba8ee5e4

用户可以根据实际需求对上述示例进行自定义的修改,有关Webhook端口的响应事件的详细信息,可以参考此文档。

扩展阅读:Webhook端口示例
EDI是什么?文章来源地址https://www.toymoban.com/news/detail-809087.html

到了这里,关于Webhook端口中的自定义签名身份认证的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Flink中的自定义参数与模型配置

    作者:禅与计算机程序设计艺术 https://nightlies.apache.org/flink/flink-docs-master/docs/concepts/flink-architecture/ Apache Flink 是一个框架和分布式处理引擎,用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行,并能以内存速度和任意规模进行计算。 在企业

    2024年02月10日
    浏览(46)
  • 身份证识别ocr、身份证实名认证接口文档

    每一次验证背后,都是对用户数据安全的承诺,对平台信誉的坚守。翔云身份证实名认证API,通过身份证识别接口仅需一键上传身份证图片即可快速识别身份证信息,翔云实名认证接口实时联网查验证件信息的真伪。 ​PHP身份证实名认证接口文档代码如下:

    2024年04月17日
    浏览(63)
  • 常见的身份认证技术

    (1)   口令认证技术(用户名/密码) 这是最简单也是最传统的身份认证方法,通过口令来验证用户的合法有效性。 通过用户名  ID  和用户密码  PW  来认证用户。 只要能够正确验证密码,系统就判定操作者是合法用户。 口令认证主要适用于小型封闭型系统。 存在的问题

    2024年02月06日
    浏览(54)
  • 鉴权与身份认证

    ​ 所谓鉴权就是 身份认证 ,就是验证您是否有权限从服务器访问或操作相关数据。通俗的讲就是一个门禁,您想要进入室内,必须通过门禁验证身份,这就是鉴权,如打开一个网站必须要输入用户名和密码才可以登录进入,这种就是鉴权,还有一些业务需要登录以后才可以

    2024年03月14日
    浏览(68)
  • NACOS身份认证绕过

    一、漏洞描述 Nacos是Alibaba的一个动态服务发现、配置和服务管理平台。攻击者通过添加Nacos-Server的User-Agent头部将可绕过(nacos.core.auth.enabled=true)鉴权认证,从而进行API操作。 二、漏洞利用 访问 http://xxxxx/nacos/v1/auth/users?username=testpassword=test ,并使用burpsuite进行抓包,将方法

    2024年02月16日
    浏览(46)
  • Nacos身份认证漏洞

    公司Nacos版本有用的2.0.1和2.0.3的都复现了身份认证的漏洞,无需认证身份就可以查看用户列表以及注册新用户,并且注册上来的新用户可以查看所有public命名空间下的配置资源! 1、查看用户列表 URL: http://ip:8848/nacos/v1/auth/users?pageNo=1pageSize=1 方法类型:GET 返回结果: 如图示

    2023年04月10日
    浏览(44)
  • ES开启身份认证

    X-Pack是Elastic Stack扩展功能,提供安全性,警报,监视,报告,机器学习和许多其他功能。 X-Pack的发展演变: 1,5.X版本之前:没有x-pack,是独立的:security安全,watch查看,alert警告等独立单元。 2,5.X版本:对原本的安全,警告,监视,图形和报告做了一个封装,形成了x-pac

    2024年02月14日
    浏览(40)
  • Nodejs七、身份认证

    1、Web 开发模式 (1)目前主流的 Web 开发模式 基于 服务端渲染 的传统 Web 开发模式 基于 前后端分离 的新型 Web 开发模式 (2)服务端渲染的 Web 开发模式 服务器发送给客户端的 HTML 页面,是在服务器通过字符串的拼接,动态生成的。 客户端不需要使用 Ajax 这样的技术额外请

    2024年02月09日
    浏览(47)
  • 数据库与身份认证

    能够知道如何配置MySQL数据库环境 能够认识并使用常见的SQL语句操作数据库 能够在Express中操作MySQL数据库 能够了解Session的实现原理 能够了解JWT的实现原理 数据库的概念 安装并配置MySQL MySQL的基本使用 在Express中操作MySQL 前后端的身份认证 数据库(database)是用来 阻止、存储和

    2024年02月10日
    浏览(45)
  • API身份认证JWT

    是一种身份认证的开放标准(RFC 7519),可以在网络应用间传输信息作为Json对象。由三部分组成:头部(Header)、载荷(payload)和签名(Signature). 头部(Header) 两部分组成,令牌类型和所使用的的签名算法   载荷(payload) 包含要传输的信息,包括用户的身份信息、权限等。载

    2024年02月13日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包