justauth/JustAuth · error · AuthException

${error_no}

${error_no}

Error message

${error_desc}

What it means

AuthXmlyRequest.checkResponse is intended to surface Ximalaya (Xmly) API errors: it throws AuthException(error_no, error_desc) with the numeric error_no as the exception code. However the guard contains a key-mismatch defect: the condition tests containsKey("errcode") while the thrown values are read from "error_no"/"error_desc". If Ximalaya actually returns `error_no` (as its API docs suggest), the check never fires; if it returns `errcode`, the exception carries code 0 and a null message.

Source

Thrown at src/main/java/me/zhyd/oauth/request/AuthXmlyRequest.java:121

        return AuthUser.builder()
            .uuid(object.getString("id"))
            .nickname(object.getString("nickname"))
            .avatar(object.getString("avatar_url"))
            .rawUserInfo(object)
            .source(source.toString())
            .token(authToken)
            .gender(AuthUserGender.UNKNOWN)
            .build();
    }

    /**
     * 校验响应结果
     *
     * @param object 接口返回的结果
     */
    private void checkResponse(JSONObject object) {
        if (object.containsKey("errcode")) {
            throw new AuthException(object.getIntValue("error_no"), object.getString("error_desc"));
        }
    }
}

View on GitHub (pinned to 694bbf1b01)

Solutions

1. Upgrade JustAuth to the latest version — check the changelog/commits for a fix to AuthXmlyRequest.checkResponse key handling.
2. If unpatched in your version, subclass AuthXmlyRequest and override/replicate checkResponse with the correct keys (`object.containsKey("error_no")`), reading error_no/error_desc.
3. Log the raw response body for Ximalaya calls until diagnosed — the exception may carry no useful text due to the mismatch.
4. Verify Ximalaya app credentials and token freshness independently via the Ximalaya docs once raw responses are visible.

Example fix

// before (library code, buggy key pair)
private void checkResponse(JSONObject object) {
    if (object.containsKey("errcode")) {
        throw new AuthException(object.getIntValue("error_no"), object.getString("error_desc"));
    }
}

// after — local subclass with consistent keys
public class FixedXmlyRequest extends AuthXmlyRequest {
    public FixedXmlyRequest(AuthConfig c) { super(c); }
    // re-implement the private checkResponse logic by overriding the public
    // entry points (getAccessToken/getUserInfo) and validating error_no there:
    // if (object.containsKey("error_no"))
    //     throw new AuthException(object.getIntValue("error_no"), object.getString("error_desc"));
}

// verify Xmly credentials present and log raw body defensively
if (StringUtils.isAnyEmpty(config.getClientId(), config.getClientSecret())) {
    throw new IllegalArgumentException("Ximalaya app_key/app_secret required");
}

try {
    AuthUser u = xmlyRequest.getUserInfo(token);
} catch (AuthException e) {
    // guard has a key mismatch: message may be null/code 0
    log.warn("Xmly failure, code={} msg={} — inspect raw response manually", e.getCode(), e.getMessage());
    redirect(xmlyRequest.authorize(newState()));
}

When it happens

Trigger: Any Ximalaya endpoint response containing an `errcode` key (per the current guard): the exception is thrown with error_no/error_desc fields which may be absent, producing AuthException(0, null). Responses containing only error_no silently pass the check.

Common situations: Ximalaya open-platform API errors (invalid app_key/app_secret, expired access token, signature failures) either being swallowed or surfacing as a codeless, messageless AuthException that is hard to diagnose; behavior differences across JustAuth versions if the key names changed.

Related errors

• ${errmsg}
• ${errmsg}
• object.getString("error_description") / object.getString("er
• object.getString("msg")
• object.getString("error")

AI-assisted analysis of justauth/JustAuth@694bbf1b01 (2026-08-14). Data as JSON: /api/errors/b0067be3a1e3e9b3. Report an issue: GitHub.