Iris框架不内置接口签名机制，因其定位是高性能轻量级Web框架，签名涉及密钥管理、算法选择等业务强相关逻辑，需开发者在中间件或handler中自行实现。
Iris 框架本身不内置接口签名机制，签名和防篡改校验必须由开发者自行实现——它只提供 ctx.Request()、ctx.JSON() 等基础能力，签名逻辑得你写在中间件或 handler 里。
为什么 Iris 不自带签名？
Iris 定位是高性能、轻量级 Web 框架，类似 Gin 或 Echo，聚焦路由、上下文、序列化等核心路径。签名涉及密钥管理、算法选择（HMAC-SHA256 / RSA / ECDSA）、时间戳容错、参数排序规范等业务强相关逻辑，框架无法也不该替你做决策。
常见错误现象包括：
- 直接把
AccessKey ID和AccessKey Secret写死在代码里，导致密钥泄露 - 忽略请求体（
body）参与签名，仅对 query 参数签名，body 被篡改后校验仍通过 - 未校验
X-Timestamp头，攻击者重放旧请求无感知
HMAC-SHA256 签名的最小可行实现
这是最常用、Iris 中落地最简单的方案。关键点在于：所有参与签名的字段必须可复现，且服务端与客户端使用完全一致的拼接规则。
推荐步骤：
- 客户端在请求头中带上
X-Access-Key（公开标识）、X-Signature（签名值）、X-Timestamp（毫秒时间戳） - 服务端中间件中：提取
ctx.Request().URL.Query()和ctx.Request().Body（需用ctx.Request().GetBody()二次读取），合并为标准 map 并按 key 字典序排序 - 拼接字符串格式为：
method|path|timestamp|sorted_query_string|body_hash（其中body_hash是原始 body 的sha256(body)，避免空 body 或 JSON 格式差异影响） - 用
hmac.New(sha256.New, []byte(secretKey))计算签名，与 header 中X-Signature对比
示例片段（中间件）：
func SignAuth(secretKey string) iris.Handler {
return func(ctx iris.Context) {
ts := ctx.GetHeader("X-Timestamp")
if ts == "" {
ctx.StatusCode(400)
_ = ctx.JSON(map[string]string{"error": "missing X-Timestamp"})
return
}
// 防重放：15分钟窗口
if time.Now().UnixMilli()-mustParseInt64(ts) > 15*60*1000 {
ctx.StatusCode(401)
_ = ctx.JSON(map[string]string{"error": "timestamp expired"})
return
}
body, _ := io.ReadAll(ctx.Request().Body)
ctx.Request().Body = io.NopCloser(bytes.NewReader(body))
query := ctx.Request().URL.Query().Encode()
bodyHash := fmt.Sprintf("%x", sha256.Sum256(body))
signStr := fmt.Sprintf("%s|%s|%s|%s|%s",
ctx.Method(), ctx.Path(), ts, query, bodyHash)
mac := hmac.New(sha256.New, []byte(secretKey))
mac.Write([]byte(signStr))
expected := fmt.Sprintf("%x", mac.Sum(nil))
if !hmac.Equal([]byte(expected), []byte(ctx.GetHeader("X-Signature"))) {
ctx.StatusCode(401)
_ = ctx.JSON(map[string]string{"error": "invalid signature"})
return
}
ctx.Next()
}
}
用 RSA/ECDSA 做非对称签名时要注意什么？
适用于更严苛场景（如医疗日志上报、跨系统调用），但复杂度明显上升。核心差异不是“怎么算”，而是“谁管密钥”和“怎么验”：
- 私钥绝对不能出现在 Iris 服务进程内存中；建议用 KMS 托管，每次验签前动态获取公钥（如从 Redis 缓存或远程 endpoint 拉取）
- 签名原文必须包含完整请求元信息：method + path + timestamp + nonce（防重放）+ body hash，缺一不可
- Iris 的
ctx.ReadBody()会消耗 body 流，务必在验签前完成读取并重置ctx.Request().Body，否则后续 handler 读不到数据 - 不要用
crypto/rsa直接解密签名，而要用rsa.VerifyPKCS1v15验证，否则可能被填充攻击绕过
数据完整性校验容易被忽略的细节
签名只是第一步，防篡改需要端到端闭环。很多团队卡在「验签通过但数据还是被改了」：
- JSON body 中字段顺序不固定（如 map 序列化），导致签名原文和服务端解析后结构不一致 → 必须统一用
json.RawMessage或预定义 struct 解析后再序列化比对 - 前端传了
"amount": "100.00"（字符串），后端解析成 float64 后再转回 JSON 可能变成"amount": 100→ 签名原文必须基于原始字节，而非 go struct - 没做响应签名：客户端无法确认返回结果是否被中间人篡改 → 敏感接口建议在 response header 中加
X-Response-Signature - 日志落库前未二次哈希：即使请求验签通过，若数据库写入时被注入恶意字段，审计时无法追溯 → 推荐在 DAO 层对关键字段计算
sha256(data)并存入独立列
真正的防篡改不是加一道签名，而是让每个环节（请求、解析、存储、响应）都有可验证的指纹。Iris 给你的是画笔，但画什么、怎么上色、留不留底稿，得你自己定规则。
