box / box/box-java-sdk

Expose additional BoxAPIRequest/BoxAPIConnection members for request intercept use case

未关闭
#488 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
enhancement
主要语言
Java
星标
170
派生
189
平均合并
20 小时 26 分钟
30 天内合并 PR
22

描述

In a Box SDK integration, I implemented a `com.box.sdk.RequestInterceptor` that uses its own HTTP client to send the requests over the network. Doing that, I noticed that in order to support this scenario, certain members should, in my opinion, be exposed to clients outside the SDK:
- `com.box.sdk.BoxAPIRequest.getHeaders()` should be public so that the corresponding content is accessible
- `com.box.sdk.BoxAPIRequest.shouldAuthenticate` should be exposed via a getter to distinguish the two cases that it indicates

In order to hold a read lock on the access token during the request (as `com.box.sdk.BoxAPIRequest.trySend(ProgressListener)` does), it would be necessary to also expose
- `com.box.sdk.BoxAPIConnection.lockAccessToken()` and
- `com.box.sdk.BoxAPIConnection.unlockAccessToken()`.

The access token can be obtained with the (already public) method `com.box.sdk.BoxAPIConnection.getAccessToken()`, but in this case there is no lock and the access token could be invalidated before the HTTP request is sent (or while it is being sent).

贡献指南

打开贡献指南

调研方向

Locate the BoxAPIRequest and BoxAPIConnection declarations, then read BoxAPIRequest.trySend(ProgressListener), getHeaders(), and the existing access-token handling. Confirm how the interceptor needs to distinguish authentication and preserve the access-token lock; done means the requested members are externally accessible without breaking the existing request behavior.

由索引模型根据 Issue 内容生成。

评估

技术栈
java
领域
api
Issue 类型
功能
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
基本清楚
新手友好度
45/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。