[BUG] 115 驱动上传超过1GB的大文件 OSS 临时凭证失效导致上传失败

请确认以下事项

• 我已确认阅读并同意 AGPL-3.0 第15条 。
  本程序不提供任何明示或暗示的担保，使用风险由您自行承担。

• 我已确认阅读并同意 AGPL-3.0 第16条 。
  无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。

• 我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。

• 我已确认阅读了OpenList文档。

• 我已确认没有重复的问题或讨论。

• 我已确认是OpenList的问题，而不是其他原因（例如 网络 ，依赖或操作）。

• 我认为此问题必须由OpenList处理，而非第三方。

• 我已确认这个问题在最新版本中没有被修复。

• 我没有阅读这个清单，只是闭眼选中了所有的复选框，请关闭这个 Issue 。

OpenList 版本（必填）

v4.2.6

使用的存储驱动（必填）

115 Open

问题描述（必填）

使用 115 Open 存储驱动上传文件时，上传失败，OSS 返回 403 鉴权错误。

目前观察到的错误包括：

StatusCode=403, ErrorCode=SecurityTokenExpired
ErrorMessage="The security token you provided has expired."

StatusCode=403, ErrorCode=InvalidAccessKeyId
ErrorMessage="The OSS Access Key Id you provided does not exist in our records."

完整错误示例：

All attempts fail:
#1: oss: service returned error: StatusCode=403, ErrorCode=SecurityTokenExpired,
ErrorMessage="The security token you provided has expired."

#2: oss: service returned error: StatusCode=403, ErrorCode=InvalidAccessKeyId,
ErrorMessage="The OSS Access Key Id you provided does not exist in our records."

#3: oss: service returned error: StatusCode=403, ErrorCode=InvalidAccessKeyId,
ErrorMessage="The OSS Access Key Id you provided does not exist in our records."

该存储使用的是 OpenList 的 115 Open 驱动，并未在 OpenList 中手动配置阿里云 OSS 的固定 AccessKey。

根据当前 115_open 驱动源码，上传流程为：

UploadInit
↓
UploadGetToken
↓
获取 115 返回的 OSS 临时凭证
↓
InitiateMultipartUpload
↓
UploadPart
↓
CompleteMultipartUpload

相关代码：

tokenResp, err := d.client.UploadGetToken(ctx)
if err != nil {
return err
}

err = d.multpartUpload(ctx, file, up, tokenResp, resp)

multpartUpload() 中通过 115 SDK 返回的以下字段创建 OSS Client：

netutil.NewOSSClient(
tokenResp.Endpoint,
tokenResp.AccessKeyId,
tokenResp.AccessKeySecret,
oss.SecurityToken(tokenResp.SecurityToken),
)

因此 OSS 使用的 AccessKeyId、AccessKeySecret 和 SecurityToken 均来自：

d.client.UploadGetToken(ctx)

而不是用户在 OpenList 配置中手动填写的 OSS 凭证。

目前怀疑问题与 115 API 返回的 OSS STS 临时凭证有效期、刷新机制或 115-sdk-go 与当前 115 上传接口之间的兼容性有关。

另外，当前 multpartUpload() 在整个 multipart 上传过程中只使用一次 UploadGetToken() 获取的临时凭证。

如果文件较大、上传时间较长，存在以下情况的可能：

UploadGetToken
↓
获取 STS 临时凭证
↓
开始 Multipart Upload
↓
上传多个 Part
↓
STS 凭证过期
↓
UploadPart 返回 SecurityTokenExpired

目前 UploadPart 外层的 retry 仅重复使用原有的 OSS Client / STS 凭证，并不会重新调用 UploadGetToken() 获取新的凭证。

希望维护者确认：

115-sdk-go 当前 UploadGetToken() 返回的 STS 凭证有效期是否发生变化；
当前 115 API 是否要求在 Multipart Upload 长时间运行过程中刷新 OSS STS 凭证；
OpenList 115_open 是否需要针对 SecurityTokenExpired 重新获取上传 Token；
InvalidAccessKeyId 是否与当前 115 上传接口返回的临时 AccessKey 失效有关；
当前 OpenList 使用的 115-sdk-go 版本是否与最新 115 上传接口兼容。

日志（必填）

All attempts fail: #1: oss: service returned error: StatusCode=403, ErrorCode=SecurityTokenExpired, ErrorMessage="The security token you provided has expired." #2: oss: service returned error: StatusCode=403, ErrorCode=InvalidAccessKeyId, ErrorMessage="The OSS Access Key Id you provided does not exist in our records." #3: oss: service returned error: StatusCode=403, ErrorCode=InvalidAccessKeyId, ErrorMessage="The OSS Access Key Id you provided does not exist in our records."

配置文件内容（必填）

115 Open 存储配置中使用的是 115 Open 驱动。

OSS 的 AccessKeyId、AccessKeySecret、SecurityToken 并非用户手动配置，而是由：

d.client.UploadGetToken(ctx)

动态获取。

相关源码：

tokenResp, err := d.client.UploadGetToken(ctx)
if err != nil {
return err
}

err = d.multpartUpload(ctx, file, up, tokenResp, resp)

以及：

ossClient, err := netutil.NewOSSClient(
tokenResp.Endpoint,
tokenResp.AccessKeyId,
tokenResp.AccessKeySecret,
oss.SecurityToken(tokenResp.SecurityToken),
)

实际配置文件中的账号、Token 等敏感信息已隐藏。

复现链接（可选）

添加 115 Open 存储驱动并完成正常授权；
确认可以正常读取目录及文件；
向 115 Open 存储上传文件；
上传过程中 OSS 返回 403；
日志出现 SecurityTokenExpired 或 InvalidAccessKeyId。

目前读取、列表等操作正常，问题主要出现在文件上传阶段。

AI生成内容

• 我使用了AI工具生成此内容
• 我没有使用AI工具生成此内容

AI模型是

GPT-5.6 Luna

Start with the 115 Open driver’s UploadGetToken and multpartUpload flow described in the issue, then trace how the OSS client is reused across multipart parts. Reproduce an upload over 1GB and compare credential lifetime with the SecurityTokenExpired and InvalidAccessKeyId failures. Done means long uploads complete without expired temporary credentials, while existing smaller uploads continue to work.