apache/incubator-seata · error · AuthenticationFailedException
No right to be identified
Error message
No right to be identified
What it means
ConsoleRemoteServiceImpl.getToken throws AuthenticationFailedException when SecurityContextHolder yields no Authentication or an unauthenticated one. The console's remote calls (to naming server / TC instances) forward the caller's JWT; without an authenticated security context there is no credential to forward, so the call is refused.
Source
Thrown at console/src/main/java/org/apache/seata/mcp/service/impl/ConsoleRemoteServiceImpl.java:81
private final NamingServerProperties namingServerProperties;
public ConsoleRemoteServiceImpl(
JwtTokenUtils jwtTokenUtils,
@Qualifier("consoleRestClient") RestClient restClient,
ObjectMapper objectMapper,
NamingServerProperties namingServerProperties) {
this.jwtTokenUtils = jwtTokenUtils;
this.restClient = restClient;
this.objectMapper = objectMapper;
this.namingServerProperties = namingServerProperties;
LOGGER.info("ConsoleRemoteServiceImpl initialized.");
}
public String getToken() {
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
if (auth == null || !auth.isAuthenticated()) {
throw new AuthenticationFailedException("No right to be identified");
}
String originJwt = (String) auth.getCredentials();
if (!jwtTokenUtils.validateToken(originJwt)) {
throw new AuthenticationFailedException("Invalid token, please log in to get a new token");
}
return WebSecurityConfig.TOKEN_PREFIX + originJwt;
}
public void setNamespaceHeaderAndQueryParam(
NameSpaceDetail nameSpaceDetail, HttpHeaders headers, Map<String, String> queryParams) {
headers.add("x-seata-namespace", nameSpaceDetail.getNamespace());
if (StringUtils.isNotBlank(nameSpaceDetail.getvGroup())) {
if (queryParams != null) {
queryParams.put("vGroup", nameSpaceDetail.getvGroup());
}
return;
}
if (nameSpaceDetail.getCluster() != null) {View on GitHub (pinned to e01f97c6db)
Solutions
- Authenticate first: log in via the console to obtain a JWT so requests carry the Bearer token
- If invoking programmatically, pass a valid token so the security filter establishes the Authentication
- When calling from non-request threads, propagate the security context (DelegatingSecurityContextExecutor) or fetch the token explicitly rather than relying on the holder
- Check WebSecurityConfig filter order if valid tokens still yield no Authentication
Defensive patterns
Strategy: try-catch
Try / catch
try { String token = service.getToken(); } catch (AuthenticationFailedException e) { return http401(e.getMessage()); } Prevention
- Authenticate and attach the JWT before any console/MCP remote call
- Propagate SecurityContextHolder to any background threads making remote calls
- Centralize token acquisition in one component so all remote paths share the guard
When it happens
Trigger: Invoking any MCP/console remote operation (getCallNameSpace, getCallTC, deleteCallTC, putCallTC...) in a session where the user never logged in, the security context was cleared (e.g. async thread without context propagation), or the request bypassed the JWT filter chain.
Common situations: Calling MCP endpoints unauthenticated, token expiry causing the filter to skip setting Authentication, executing remote calls on a background/scheduled thread where SecurityContextHolder is not propagated, or misordered security filter config letting requests through without auth.
Related errors
- Invalid token, please log in to get a new token
- No naming servers addr configured
- The time format does not match yyyy-MM-dd
- The time format does not match yyyy-MM-dd HH:mm:ss
- MCP GET request failed with status: %s, response: %s
AI-assisted analysis of apache/incubator-seata@e01f97c6db (2026-08-14).
Data as JSON: /api/errors/1a72b064403872d2.
Report an issue: GitHub.