flipped-aurora/gin-vue-admin · error
无效签名
Error message
无效签名
What it means
TokenSignatureInvalid is returned by ParseToken when the JWT's signature fails verification: the token was signed with a key different from JWT.SigningKey, or its payload/signature segments were altered after issuance.
Source
Thrown at server/utils/jwt.go:22
"context"
"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)), // 签名生效时间View on GitHub (pinned to 3136500ef3)
Solutions
- Ensure every server instance uses the same JWT.SigningKey value in config.yaml (or shared secret manager).
- Re-login/re-issue the token after any signing-key rotation.
- If this is a dev/prod mix-up, use the token issued for the environment you are calling.
- Diff the signing key against the issuer's to confirm which mismatch exists before rotating.
Example fix
// before # node A config.yaml jwt: signing-key: 'abc' # node B config.yaml jwt: signing-key: 'xyz' # tokens from A fail on B: 无效签名 // after jwt: signing-key: 'abc' # identical on all nodes
Defensive patterns
Strategy: validation
Validate before calling
// ops check before deploy
// grep -r 'signing-key' server/config.yaml -> must match issuer's key
if cfg.JWT.SigningKey == "" || cfg.JWT.SigningKey != expectedKey {
return errors.New("signing key mismatch across nodes")
} Try / catch
claims, err := utils.ParseToken(token)
if errors.Is(err, utils.TokenSignatureInvalid) {
// token from another environment or tampered: reject, force re-login
return nil, ErrSignatureMismatch
} Prevention
- Distribute JWT.SigningKey via a shared secret store so all replicas match
- Rotate keys deliberately: bump a key-version, re-issue tokens, keep old key for a grace window
- Never hand-edit token payload segments; signature verification will reject them
When it happens
Trigger: Tokens issued by an environment whose JWT.SigningKey differs from the validating server's config; manually edited tokens; key rotation on the server invalidating previously issued tokens.
Common situations: Multi-node deployments with inconsistent config.yaml signing keys; dev/prod keys mixed up (token from dev used against prod); a config change rotating the key while clients still hold old tokens.
Related errors
AI-assisted analysis of flipped-aurora/gin-vue-admin@3136500ef3 (2026-08-31).
Data as JSON: /api/errors/02da42ccf6737126.
Report an issue: GitHub.