Gin框架接口权限控制实例-Golang-PHP中文网

gin-jwt.authorizer不足以做路径级权限，因其仅在令牌验证后执行一次，不自动获取请求method和path，需手动解析易出错；它适合快速拒绝，细粒度授权应交由casbin等方案实现。

gin框架接口权限控制实例

直接用 gin-jwt 做接口权限控制，容易卡在“角色写了但没生效”“路径匹配不上”“中间件顺序错导致跳过校验”这三类问题上。它本身只负责认证（确认身份），不处理授权（能访问什么），必须配合额外逻辑或第三方库才能真正控权。

为什么 gin-jwt.Authorizer 不足以做路径级权限？

gin-jwt 的 Authorizer 函数只在令牌验证通过后执行一次，且只接收 *gin.Context 和原始 data（比如用户结构体），无法自动感知当前请求的 method 和 path 细节——除非你手动从 c.Request 里取，但这样写死路径判断会很快失控。

常见错误现象：

写了 c.Request.URL.Path == "/admin"，但实际路由是 GET /api/v1/admin/users，字符串不匹配就放行
没检查 c.Request.Method，导致 DELETE /users 和 GET /users 权限混用
Authorizer 返回 true 后，后续中间件或 handler 仍可能绕过权限逻辑

可行做法：

把路径和方法提取逻辑封装进一个统一函数，例如 getResourceAction(c *gin.Context) (string, string)，返回类似 "user:read" 或 "admin:write" 这样的抽象标识
在 Authorizer 中调用该函数，再查表或策略做判断，避免硬编码路径字符串
不要依赖 Authorizer 做全部授权，它更适合做“快速拒绝”，细粒度控制交给后续中间件

用 Casbin 实现 RBAC 路径权限的最小可行配置

Casbin 是目前 Gin 生态中最稳妥的授权方案，它把“谁（subject）能对什么资源（object）执行什么操作（action）”拆开管理，模型与策略分离，改权限不用动代码。

关键步骤：

定义模型文件 rbac_model.conf，内容必须包含 [request_definition]、[policy_definition]、[role_definition] 和 [policy_effect] 四段，少一段都会 panic
策略数据建议存 Redis 或数据库，避免重启丢失；开发期可用 casbin.NewEnforcer("rbac_model.conf", "rbac_policy.csv")
在 JWT 中间件之后、业务 handler 之前插入 Casbin 中间件，确保 c.MustGet("currentUser") 已存在且含角色信息
Casbin 校验调用形如 e.Enforce(role, path, method)，其中 path 应该是标准化后的资源标识（如 "/api/v1/users"），不是带参数的完整 URL

示例中间件片段：

Gin框架 1.9.0

Gin框架 1.9.0版本源码包下载，版本号 1.9.0，适合需要 sonic JSON 支持、路由修复和内容协商改进的 Go Web 开发场景。

下载

func CasbinMiddleware(e *casbin.Enforcer) gin.HandlerFunc {
    return func(c *gin.Context) {
        role, _ := c.Get("role")
        path := c.Request.URL.Path
        method := c.Request.Method

        // 注意：path 需提前清洗，比如去掉 /api/v1 前缀或映射到资源名
        if !e.Enforce(role, path, method) {
            c.AbortWithStatusJSON(403, gin.H{"msg": "permission denied"})
            return
        }
        c.Next()
    }
}

路由分组 + 中间件组合才是生产级权限落地方式

别指望一个中间件包打天下。真实项目中，权限控制是分层的：路由前缀决定基础访问域，JWT 确认身份，Casbin 判定动作，最后业务层再做数据级过滤（比如“只能看自己创建的订单”）。

典型分组写法：

public := r.Group("/api/v1") —— 不挂任何权限中间件，开放接口如登录、注册、健康检查
user := r.Group("/api/v1/user") —— 挂 JWTMiddleware()，只认证，不控角色
admin := r.Group("/api/v1/admin") —— 挂 JWTMiddleware() + CasbinMiddleware(e)，且 Casbin 策略里明确限定 admin 角色对 /api/v1/admin/* 的 full 权限

容易踩的坑：

中间件顺序写反：把 CasbinMiddleware 放在 JWTMiddleware 前面，会导致 c.Get("role") 取不到值，直接 403
路由组前缀和 Casbin 策略里的 resource 不一致，比如策略写 /admin 但路由是 /api/v1/admin，匹配失败
没处理 OPTIONS 预检请求，导致前端跨域时被 Casbin 拦截，应加 AllowMethodAndPathPrefixSkipper() 类跳过逻辑