fix: 修复 authen v1 token 接口请求格式 (#196)#197
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 46100261ac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| impl ApiResponseTrait for UserAccessTokenV1ResponseData { | ||
| fn data_format() -> ResponseFormat { | ||
| ResponseFormat::Data | ||
| ResponseFormat::Flatten |
There was a problem hiding this comment.
When these token APIs use ResponseFormat::Flatten, they are handled by handle_flatten_response, which currently emits debug!("Raw response: {response_text}") before parsing. For successful access-token/refresh-token calls, that raw JSON contains access_token and often refresh_token, so enabling debug logs leaks live credentials; the standard Data path explicitly avoids raw response logging for this reason. Please either remove/redact the flatten raw-response log or avoid sending credential-bearing responses through that handler.
Useful? React with 👍 / 👎.
| ApiRequest::post(api_endpoint.path()).body(serde_json::to_value(&request_body)?); | ||
| ApiRequest::post(api_endpoint.path()) | ||
| .body(serde_json::to_value(&request_body)?) | ||
| .with_supported_access_token_types(vec![AccessTokenType::App]); |
There was a problem hiding this comment.
When enable_token_cache(false) is used, determine_token_type ignores this supported-token override and picks user_access_token before app_access_token. Since this endpoint is now marked app-only, a reused RequestOption containing a user token (even alongside an app token) sends Authorization: Bearer <user> to an app-auth endpoint and fails; please either reject unsupported explicit tokens or force the App token for these calls.
Useful? React with 👍 / 👎.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c33d57fbd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
| } | ||
|
|
||
| return AccessTokenType::None; |
There was a problem hiding this comment.
When token cache is disabled and a request now constrains tokens to vec![AccessTokenType::App], this new fallback returns None if the caller omits app_access_token or only passes an unsupported user/tenant token. validate explicitly allows AccessTokenType::None, so the four newly app-only authen token calls proceed without any Authorization header instead of failing locally for the missing app token; the new early return here is the fresh evidence beyond the earlier user-vs-app selection issue. Please keep the requested token type (so AuthHandler reports the missing app token) or reject unsupported explicit tokens rather than silently sending an unauthenticated request.
Useful? React with 👍 / 👎.
1 participant
摘要
验证