Slack如何验证交互请求？签名密钥校验交互请求异常问题

你遇到的是Slack签名校验场景下的高频踩坑点，Slack所有对外推送的请求（斜杠命令、Block Kit交互、全局快捷键、事件订阅）用的是完全一致的签名校验规则，不存在交互请求单独适配一套哈希算法的情况，校验失败的核心原因几乎都是请求体预处理环节出了问题。

签名校验的统一规则 #

所有请求的签名计算逻辑固定为三步，和请求体内的业务结构无关：

• 从请求头提取X-Slack-Request-Timestamp字段值，先做防重放判断：如果当前服务器时间和该时间戳差值超过5分钟，直接判定为非法请求
• 拼接签名基准字符串，格式固定为 v0:${timestamp}:${原始请求体完整字符串}
• 用应用的Signing Secret作为密钥，对上述基准字符串做HMAC-SHA256运算，结果拼接v0=前缀后，和请求头X-Slack-Signature字段值做常量时间相等对比，一致则为合法请求

注意：基准字符串里的请求体部分，必须是HTTP请求到达你服务时的完全原始的字节流转码结果，不能做任何解析、重排、转码、解码操作，哪怕只是多了一个空格、参数顺序变了、url编码规则有细微差异，最终哈希结果都会完全不匹配。

交互请求校验失败的常见原因 #

你能正常校验斜杠命令、但校验不了Block交互请求，基本是以下两个错误操作导致的：

• 你的Web框架默认开启了请求体自动解析：Slack交互请求的Content-Type是application/x-www-form-urlencoded，框架会自动把原始请求体解析为键值对对象，你后续拿解析后重新序列化的内容计算哈希——只要重序列化的内容和原始请求体有任何字符级差异，哈希就对不上
• 错误提取了计算用的请求体内容：交互请求的所有业务数据都存在form表单的payload字段里，是url编码后的JSON字符串，很多人会单独把payload字段解码后的JSON内容拿来算哈希，漏掉了外层的payload=前缀和对应的url编码部分，自然算不出正确结果

举个实际例子：交互请求的原始请求体长这样 payload=%7B%22type%22%3A%22block_actions%22%2C...%7D，如果你把url解码后的{"type":"block_actions",...}字符串单独拿去算签名，结果必然不匹配，必须把payload=开头的完整原始字符串纳入计算。

修复方法 #

• 调整服务的请求处理逻辑：在所有body解析中间件执行前，先把请求的原始字节流完整缓存下来，全程不做任何修改，专门用于签名校验
• 不要针对斜杠命令、交互请求写两套签名计算逻辑，所有Slack来源的请求统一用缓存的raw body按固定规则计算签名
• 签名校验通过后，再做业务层面的请求体解析：斜杠命令直接解析form参数即可，交互请求提取form中payload字段的值做JSON解码，就能拿到完整的Block交互结构

目前Slack已经全量下线了verification token的支持，新创建的应用已经无法获取该字段，签名校验是唯一官方支持的长期兼容方案，不需要再找其他校验路径，把raw body获取的问题修复即可正常通过校验。

内容的提问来源于stack exchange，提问作者nbpeth