EvaporateJS恢复上传后始终报403 SignatureDoesNotMatch错误

问题现象 #

• 遵循官方文档与示例配置EvaporateJS，服务端AWS v4签名程序运行正常，普通multipart分片上传流程可完整完成
• 执行暂停上传任务后再触发恢复操作，恢复后发出的首个PUT请求固定返回403 (SignatureDoesNotMatch)错误

问题排查 #

初步定位确认：恢复上传后的首次请求中，EvaporateJS向服务端传递了错误的stringToSign用于签名计算。

暂停前最后一次请求的待签名字符串内容：

AWS4-HMAC-SHA256 
20220608T114339Z 
20220608/default/s3/aws4_request 
b45c4ca1a7c7744ea2f3b6507bd3452317773cf30b860f4d98de662b8f7a85b6

恢复上传后首个请求的待签名字符串内容：

AWS4-HMAC-SHA256
20220608T114345Z
20220608/default/s3/aws4_request
b45c4ca1a7c7744ea2f3b6507bd3452317773cf30b860f4d98de662b8f7a85b6

对比两份内容可见：待签名字符串的时间戳已经更新为恢复操作时的新时间，但canonicalRequest对应的哈希值完全没有更新，直接复用了暂停前的旧哈希值，最终导致签名计算结果和请求实际内容不匹配，触发403错误。

修复方案 #

• 优先升级EvaporateJS到2.1.4及以上稳定版本，该问题为旧版本已知逻辑缺陷：暂停恢复流程未清空上一次请求缓存的规范请求哈希值，恢复时直接用旧哈希搭配新时间戳生成待签名字符串，必然触发签名校验失败。
• 若暂时无法升级版本，可在调用恢复上传方法前，手动清除当前上传任务实例上缓存的cachedCanonicalRequest、lastSignature相关属性，强制恢复后的首个请求重新计算全量待签名内容，不复用暂停前的缓存值。
• 额外校验服务端签名逻辑：签名计算使用的时间戳必须完全取EvaporateJS请求中携带的x-amz-date头值，不要在服务端自行生成当前时间戳参与计算，否则也会触发同类签名不匹配错误。

内容的提问来源于stack exchange，提问作者Mehran Rezaei