apache/rocketmq · error · AuthenticationException

User:{} is not found

Error message

User:{} is not found

What it means

isSuperUser(username) chains getUser and rejects when the lookup yields null: the authorization check cannot decide super-user status for an unknown account, so it fails closed with AuthenticationException instead of returning false.

Source

Thrown at auth/src/main/java/org/apache/rocketmq/auth/authentication/manager/AuthenticationMetadataManagerImpl.java:186

        return result;
    }

    @Override
    public CompletableFuture<List<User>> listUser(String filter) {
        CompletableFuture<List<User>> result = new CompletableFuture<>();
        try {
            result = this.getAuthenticationMetadataProvider().listUser(filter);
        } catch (Exception e) {
            this.handleException(e, result);
        }
        return result;
    }

    @Override
    public CompletableFuture<Boolean> isSuperUser(String username) {
        return this.getUser(username).thenApply(user -> {
            if (user == null) {
                throw new AuthenticationException("User:{} is not found", username);
            }
            return user.getUserType() == UserType.SUPER;
        });
    }

    private void validate(User user, boolean isCreate) {
        if (user == null) {
            throw new AuthenticationException("user can not be null");
        }
        if (StringUtils.isBlank(user.getUsername())) {
            throw new AuthenticationException("username can not be blank");
        }
        if (isCreate && StringUtils.isBlank(user.getPassword())) {
            throw new AuthenticationException("password can not be blank");
        }
    }

    private void handleException(Exception e, CompletableFuture<?> result) {

View on GitHub (pinned to 293f588571)

Solutions

  1. Create the referenced user in the metadata store, or remove/fix ACL entries and calls that reference it.
  2. Treat a missing user as non-super defensively at the call site: catch the AuthenticationException (or pre-check getUser) and return false when appropriate.
  3. Keep user deletion coordinated with ACL cleanup so authorization never sees dangling usernames.

Example fix

// before
boolean sup = authManager.isSuperUser(username).join(); // throws for unknown user

// after
boolean sup = authManager.getUser(username)
    .thenApply(u -> u != null && u.getUserType() == UserType.SUPER)
    .exceptionally(e -> false)
    .join();
Defensive patterns

Strategy: fallback

Validate before calling

// Pre-check existence before deciding super-user status
authManager.getUser(username)
    .thenApply(u -> u != null && u.getUserType() == UserType.SUPER);

Try / catch

catch (AuthenticationException | CompletionException e) { if cause message contains "is not found" -> default to false (deny) and log the dangling username for ACL cleanup. }

Prevention

When it happens

Trigger: Calling isSuperUser for a user that was never created or has been deleted - commonly on the server's internal authorization path (e.g. evaluating an ACL that requires SUPER type) with a username that is not in the metadata store.

Common situations: ACL evaluations after a user was deleted but connections/sessions still active; misconfigured ACL rules referencing unknown users; health or admin checks probing usernames that do not exist.

Related errors


AI-assisted analysis of apache/rocketmq@293f588571 (2026-08-14). Data as JSON: /api/errors/7f10ed4eccde1baa. Report an issue: GitHub.