What causes "无法处理此token" in flipped-aurora/gin-vue-admin?

Log the raw jwt error inside ParseToken to identify which validation failed and map it to a proper sentinel.

无法处理此token

Error message

无法处理此token

What it means

TokenInvalid is the generic 'cannot process this token' sentinel returned by ParseToken for jwt library errors that indicate the token is unusable but do not match the more specific sentinels (expired, not-valid-yet, malformed, signature). It is thejwt parse fallback for structurally rejected tokens.

Source

Thrown at server/utils/jwt.go:23

	"errors"
	"time"

	"github.com/flipped-aurora/gin-vue-admin/server/global"
	"github.com/flipped-aurora/gin-vue-admin/server/model/system/request"
	jwt "github.com/golang-jwt/jwt/v5"
)

type JWT struct {
	SigningKey []byte
}

var (
	TokenValid            = errors.New("未知错误")
	TokenExpired          = errors.New("token已过期")
	TokenNotValidYet      = errors.New("token尚未激活")
	TokenMalformed        = errors.New("这不是一个token")
	TokenSignatureInvalid = errors.New("无效签名")
	TokenInvalid          = errors.New("无法处理此token")
)

func NewJWT() *JWT {
	return &JWT{
		[]byte(global.GVA_CONFIG.JWT.SigningKey),
	}
}

func (j *JWT) CreateClaims(baseClaims request.BaseClaims) request.CustomClaims {
	bf, _ := ParseDuration(global.GVA_CONFIG.JWT.BufferTime)
	ep, _ := ParseDuration(global.GVA_CONFIG.JWT.ExpiresTime)
	claims := request.CustomClaims{
		BaseClaims: baseClaims,
		BufferTime: int64(bf / time.Second), // 缓冲时间1天 缓冲时间内会获得新的token刷新令牌 此时一个用户会存在两个有效令牌 但是前端只留一个 另一个会丢失
		RegisteredClaims: jwt.RegisteredClaims{
			Audience:  jwt.ClaimStrings{"GVA"},                   // 受众
			NotBefore: jwt.NewNumericDate(time.Now().Add(-1000)), // 签名生效时间
			ExpiresAt: jwt.NewNumericDate(time.Now().Add(ep)),    // 过期时间 7天  配置文件

View on GitHub (pinned to 3136500ef3)

Solutions

Log the raw jwt error inside ParseToken to identify which validation failed and map it to a proper sentinel.
Re-issue the token with the expected signing method (HS256 with the configured key) and correctly typed claims (numeric exp/nbf).
Verify the token issuer uses the same golang-jwt major version and claim conventions.
If a library upgrade introduced it, check the jwt library migration notes for new default validations.

Example fix

// before
token := makeTokenWithAlg("none") // unexpected signing method
claims, err := utils.ParseToken(token) // 无法处理此token
// after
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims) // expected alg
signed, _ := token.SignedString(key)
claims, err := utils.ParseToken(signed) // ok

Defensive patterns

Strategy: try-catch

Validate before calling

header := parts[0]
alg := base64DecodeJSON(header)["alg"]
if alg != "HS256" {
    return errors.New("unsupported signing method")
}

Try / catch

claims, err := utils.ParseToken(token)
if err != nil {
    switch {
    case errors.Is(err, utils.TokenExpired):
        handleExpired()
    case errors.Is(err, utils.TokenInvalid):
        // generic rejection; log raw jwt error to identify the unmapped cause
        log.Warn("token invalid: %v", rawErr)
        reject401()
    }
}

Prevention

Issue tokens with the same jwt library version and HS256 signing method used for validation
Ensure claims use expected types (numeric exp/nbf/iat)
Keep ParseToken's error mapping in sync with the jwt library version in go.mod when upgrading

When it happens

Trigger: jwt.Parse returns an error outside the known switch in ParseToken — e.g. unsupported signing method (alg not HS256-style expected by this code), claim-type mismatches, or library-specific validation errors after token structure and signature checks.

Common situations: Tokens minted by another implementation using an unexpected alg; claims with unexpected types (e.g. exp as string not number); upgrading golang-jwt introduces new validation errors mapped to the default branch.

Related errors

AI-assisted analysis of flipped-aurora/gin-vue-admin@3136500ef3 (2026-08-31). Data as JSON: /api/errors/af036cd2f64a4d89. Report an issue: GitHub.