Iris框架JWT怎么验证？请求头Token解析中间件-Golang-PHP中文网

jwt验证中间件必须显式调用j.serve挂载，extractor需按实际来源配置，验证失败时自定义error回调必须手动调用ctx.stopexecution()，密钥与signingmethod须严格匹配。

iris框架jwt怎么验证？请求头token解析中间件

JWT验证中间件必须显式调用 `j.Serve`，不能只注册不挂载

很多人把 jwt.New() 返回的中间件实例存起来就以为完事了，结果请求始终不触发验证。Iris 的 JWT 中间件不是全局自动生效的——它只是一个 iris.Handler，必须像普通路由处理器一样，明确传给 app.Get()、app.Use() 或路由组的 .Use()。

常见错误写法：

j := jwt.New(jwt.Config{...})
// ❌ 没有挂载，/secured 路由完全绕过验证
app.Get("/secured", myAuthenticatedHandler)

正确做法是把 j.Serve 作为中间件链一环插入：

app.Get("/secured", j.Serve, myAuthenticatedHandler) —— 单路由启用
admin := app.Party("/admin"); admin.Use(j.Serve); admin.Get("/users", handler) —— 路由组启用
app.Use(j.Serve) —— 全局启用（慎用，静态资源、登录接口等不该被拦截）

`Extractor` 配置决定从哪取 Token，别依赖默认值

Iris JWT 默认从 Authorization: Bearer <token></token> 提取，但很多前端发请求时习惯塞在 URL 参数（如 ?token=xxx）或自定义 Header（如 X-Auth-Token）。这时候必须显式配置 Extractor，否则 j.Serve 会直接解析失败返回 401。

常用提取方式：

从 URL 参数：Extractor: jwt.FromParameter("token")
从自定义 Header：Extractor: jwt.FromHeader("X-Auth-Token")
从 Cookie：Extractor: jwt.FromCookie("auth_token")
支持多源 fallback：jwt.FromFirst(jwt.FromHeader("Authorization"), jwt.FromParameter("token"))

注意：FromHeader("Authorization") 仍要求值格式为 Bearer xxx，如果前端只传 xxx，需自定义 extractor 函数处理。

Token Analyzer

基于官方 GMGN API 的代币分析工具。通过合约地址查询代币在 SOL/BSC/Base 链上的准确市场数据、安全检测、KOL 分析、开发者分析和 AI 智能分析（叙事/筹码/老鼠仓/机器人）。支持自动识别链。

下载

验证失败必须调用 `ctx.StopExecution()`，否则后续逻辑照常执行

这是最隐蔽也最危险的坑。JWT 中间件内部遇到签名错误、过期、密钥不匹配等情况时，会写入 401 响应并调用 ctx.StopExecution() —— 但这个行为**仅发生在你没重写 Config.Error 的前提下**。

一旦你自定义了 Error 回调（比如想统一返回 JSON 格式错误），就必须手动补上 ctx.StopExecution()，否则 ctx.Next() 仍会被执行，导致鉴权失败后业务 handler 照常运行：

j := jwt.New(jwt.Config{
    Extractor: jwt.FromHeader("Authorization"),
    ValidationKeyGetter: func(t *jwt.Token) (interface{}, error) {
        return []byte("My Secret"), nil
    },
    Error: func(ctx iris.Context, err error) {
        ctx.StatusCode(401)
        ctx.JSON(iris.Map{"error": "invalid token"})
        ctx.StopExecution() // ✅ 必须加这一行
    },
})

漏掉 ctx.StopExecution() 的后果：日志里看不到错误、数据库可能被非法查询、权限校验形同虚设。

密钥和签名算法必须严格匹配，`SigningMethod` 错配会导致静默失败

生成 Token 时用的是 jwt.SigningMethodHS256，验证时 Config.SigningMethod 就必须设成同一个；如果用 RSA 私钥签名，验证端就得用公钥 + SigningMethodRS256。错配不会 panic，而是让 jwt.ParseWithClaims 内部返回 ErrSignatureInvalid，最终进 Error 回调。

还要核对两处密钥一致性：