iflytek/astron-agent · warning · BusinessException
EXCEED_AUTHORITY
EXCEED_AUTHORITY
Error message
EXCEED_AUTHORITY
What it means
DataPermissionCheckTool.deny(action, resource) is the central access-denied exit for all ownership/visibility checks (checkRepoBelong, checkRepoVisible, checkToolBelong, checkFileBelong, checkToolVisible, checkBotBelong, ...). When the resource's spaceId/owner uid does not match the current Space context or current user (and the user is not public-visible or admin), it logs a warn with action, uid, spaceId and resource type, then throws BusinessException(EXCEED_AUTHORITY). This is the platform's 'you are not allowed to touch this resource' signal, not a bug in the calling code per se.
Solutions
- Confirm from the warn log ('Permission check failed: action=..., uid=..., currentSpaceId=..., resourceType=...') whether the mismatch is user-based or space-based.
- Operate within the correct space: send the request with the space context matching the resource's spaceId, or switch spaces in the console.
- Use resources owned by the authenticated uid, or have the owner/grantor publish the resource (isPublic=true) or add proper group visibility so the check passes legitimately.
- If access should genuinely be granted, have an administrator perform the operation or adjust the visibility/ownership data in the corresponding tables — do not bypass the check in code.
Example fix
// before — caller uses whatever repo id arrives
Repo repo = repoMapper.selectById(repoId);
dataPermissionCheckTool.checkRepoBelong(repo);
// after — return a clean 403 to the client instead of leaking a raw 500
try {
dataPermissionCheckTool.checkRepoBelong(repo);
} catch (BusinessException e) {
if (ResponseEnum.EXCEED_AUTHORITY.equals(e.getEnum())) {
throw new BusinessException(ResponseEnum.EXCEED_AUTHORITY, "repo " + repoId + " is not accessible in current space");
}
throw e;
} Defensive patterns
Strategy: validation
Validate before calling
// caller-side pre-check mirroring the tool's rule
String uid = UserInfoManagerHandler.getUserId();
Long spaceId = SpaceInfoUtil.getSpaceId();
boolean allowed = spaceId != null
? Objects.equals(repo.getSpaceId(), spaceId)
: Objects.equals(repo.getUserId(), String.valueOf(uid));
if (!allowed && !Boolean.TRUE.equals(repo.getIsPublic())) {
throw new BusinessException(ResponseEnum.EXCEED_AUTHORITY);
} Try / catch
try {
dataPermissionCheckTool.checkRepoVisible(repo);
} catch (BusinessException e) {
if (ResponseEnum.EXCEED_AUTHORITY.equals(e.getEnum())) {
log.warn("access denied by permission check, resource={}, space={}", repo.getId(), SpaceInfoUtil.getSpaceId());
throw new BusinessException(ResponseEnum.EXCEED_AUTHORITY, "resource not accessible in current space");
}
throw e;
} Prevention
- Always send the correct space header so SpaceInfoUtil context matches the resource being accessed.
- Check the warn log 'Permission check failed: action=..., uid=..., currentSpaceId=...' to diagnose ownership vs space mismatches.
- Verify resource visibility (isPublic / group visibility) before sharing links to other users' repos, tools or bots.
- Use the owning account or an admin for administrative operations instead of retrying a denied request.
When it happens
Trigger: Accessing (read/update/delete) a repo, tool, file, bot, workflow, DB or eval resource owned by another user when no Space context is set (SpaceInfoUtil.getSpaceId()==null and resource.getUserId() != current uid), or accessing a resource whose spaceId differs from the current space header; also when the resource is not public and the caller is not the configured admin uid.
Common situations: User A trying to edit/delete User B's bot, tool or knowledge repo via forged or stale IDs; a member operating in the wrong space (space header/X-Space-Id pointing to another space than the resource's); sharing/visibility rules changed so a formerly group-visible resource is now private; automation scripts reusing another account's resources.
Understand the failure class
Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.
Related errors
AI-assisted analysis of iflytek/astron-agent@5e758547a8 (2026-09-12).
Data as JSON: /api/errors/2fff03aeb0ef5c3a.
Report an issue: GitHub.
Appendix: source
Thrown at console/backend/toolkit/src/main/java/com/iflytek/astron/console/toolkit/tool/DataPermissionCheckTool.java:131
return ownerUid != null && ownerUid.equals(bizConfig.getAdminUid());
}
/**
* Throw access denied exception when resource is not visible (and print necessary context).
*
* @param action the action being performed
* @param resource the resource being accessed
* @throws BusinessException with EXCEED_AUTHORITY error
*/
private void deny(String action, Object resource) {
String uid = UserInfoManagerHandler.getUserId();
log.warn(
"Permission check failed: action={}, uid={}, currentSpaceId={}, resourceType={}",
action,
uid,
currentSpaceId(),
resource == null ? null : resource.getClass().getSimpleName());
throw new BusinessException(ResponseEnum.EXCEED_AUTHORITY);
}
// ===================== Repo / Tool / File =====================
/**
* Check repository ownership.
*
* @param repo the repository to check
* @throws BusinessException if access denied or data not exists
*/
public void checkRepoBelong(Repo repo) {
if (repo == null)
throw new BusinessException(ResponseEnum.DATA_NOT_EXIST);
String uid = getThreadLocalUidNoNull();
Long spaceId = currentSpaceId();
boolean noPermission = spaceId != null
? !Objects.equals(repo.getSpaceId(), spaceId)View on GitHub (pinned to 5e758547a8)