jeecgboot/JeecgBoot · warning · AuthenticationException

登录租户授权变更，请重新登陆!

Error message

登录租户授权变更，请重新登陆!

What it means

Thrown by ShiroRealm.checkUserTokenIsEffect() during multi-tenant validation when the tenant ID in the request context (TenantContext) does not match any tenant ID in the user's relTenantIds, even after re-querying the database for fresh data. This detects when a user's tenant authorization was revoked or changed after login — the token is still valid but the tenant access is no longer authorized.

Source

Thrown at jeecg-boot/jeecg-boot-base-core/src/main/java/org/jeecg/config/shiro/ShiroRealm.java:178

                    boolean isAuthorization = false;
                    //========================================================================
                    // 查询用户信息（如果租户不匹配从数据库中重新查询一次用户信息）
                    String loginUserKey = CacheConstant.SYS_USERS_CACHE + "::" + username;
                    redisUtil.del(loginUserKey);
                    LoginUser loginUserFromDb = commonApi.getUserByName(username);
                    if (oConvertUtils.isNotEmpty(loginUserFromDb.getRelTenantIds())) {
                        String[] newArray = loginUserFromDb.getRelTenantIds().split(",");
                        if (oConvertUtils.isIn(contextTenantId, newArray)) { 
                            isAuthorization = true;
                        }
                    }
                    //========================================================================

                    //*********************************************
                    if(!isAuthorization){
                        log.info("租户异常——登录租户：" + contextTenantId);
                        log.info("租户异常——用户拥有租户组：" + userTenantIds);
                        throw new AuthenticationException("登录租户授权变更，请重新登陆!");
                    }
                    //*********************************************
                }
            }
        }
        return loginUser;
    }

    /**
     * JWTToken刷新生命周期 （实现： 用户在线操作不掉线功能）
     * 1、登录成功后将用户的JWT生成的Token作为k、v存储到cache缓存里面(这时候k、v值一样)，缓存有效期设置为Jwt有效时间的2倍
     * 2、当该用户再次请求时，通过JWTFilter层层校验之后会进入到doGetAuthenticationInfo进行身份验证
     * 3、当该用户这次请求jwt生成的token值已经超时，但该token对应cache中的k还是存在，则表示该用户一直在操作只是JWT的token失效了，程序会给token对应的k映射的v值重新生成JWTToken并覆盖v值，该缓存生命周期重新计算
     * 4、当该用户这次请求jwt在生成的token值已经超时，并在cache中不存在对应的k，则表示该用户账户空闲超时，返回用户信息已失效，请重新登录。
     * 注意： 前端请求Header中设置Authorization保持不变，校验有效性以缓存中的token为准。
     *       用户过期时间 = Jwt有效时间 * 2。
     *
     * @param userName

View on GitHub (pinned to 96fb33f5ec)

Solutions

  1. Have the user log out and log in again to get a fresh token with updated tenant assignments.
  2. Administrator verifies the user's current tenant assignments in sys_user.rel_tenant_ids.
  3. If the tenant assignment is correct but the token is stale, clear the user's Redis cache (SYS_USERS_CACHE key) and have them re-login.
  4. Check that the front-end sends the correct X-TENANT-ID header matching the user's assigned tenant.

Example fix

-- Verify user's tenant assignments
SELECT username, rel_tenant_ids FROM sys_user WHERE username = '<username>';
-- If tenant was removed, re-add it:
UPDATE sys_user SET rel_tenant_ids = '0,1,2' WHERE username = '<username>';
-- Clear user cache, then user logs out and logs in again.
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify tenant assignment before relying on a cached token
// Admin: SELECT username, rel_tenant_ids FROM sys_user WHERE username = '<username>'
// If tenant was removed, re-add it before the user tries to access

Try / catch

// Handled by JwtFilter — returns 401 '登录租户授权变更'
// Front-end: on this message, force logout and re-login
axios.interceptors.response.use(null, error => {
    if (error.response?.data?.message?.includes('租户授权变更')) {
        store.dispatch('Logout');
        router.push('/user/login');
    }
});

Prevention

When it happens

Trigger: Admin removes a tenant from a user's relTenantIds while the user is logged in with that tenant selected; user switches tenant in the front-end but their authorization was revoked; the X-TENANT-ID header in the request does not match any tenant the user currently has access to.

Common situations: Admin reassigns tenant permissions after an organizational change; user's tenant contract expired; tenant ID was manually set in the request header to a value the user lost access to; multi-tenant data was migrated and tenant assignments changed.

Related errors

AI-assisted analysis of jeecgboot/JeecgBoot@96fb33f5ec (2026-08-14). Data as JSON: /api/errors/d9657d0843278a58. Report an issue: GitHub.