S3文件上传403问题排查

原创 吴就业 135 0 2023-06-09

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/debd6d78d3c342d3ad1d55419c5227d3

作者:吴就业
链接:https://wujiuye.com/article/debd6d78d3c342d3ad1d55419c5227d3
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

业务反馈有个iOS设备上传出现403问题,打点日记只能看到403,没有详细的错误信息。

开了s3的日记后,也只是看到403 AccessDenied。根据常见的AccessDenied,排除了客户端时间设置问题。

问s3的人是否可以查到具体的错误,答案也是看不到。

服务端是aws的服务,客户端直传s3,靠自己查怎么查呢?

想到两个排查方案:

  1. 一是客户端sdk打印详细body,但需要发app版本,让用户升级。(不可行)
  2. 另一个方案是开发一个s3上传的代理服务,由于客户端请求临时凭证是向自己的后端服务请求的,而不是aws的s3服务,并且上传的域名也是在临时凭证接口下发的,因此我们通过修改临时凭证接口不下发s3的域名,而是下发代理服务的域名,在代理服务打印详细的日记信息进一步排查。缺点是会影响整体的总上传耗时。

代理服务上线后,观察到所有403的请求,响应body如下:

<?xml version="1.0" encoding="UTF-8"?>
<Error>
    <Code>AccessDenied</Code>
    <Message>AWS authentication requires a valid Date or x-amz-date header</Message>
    <RequestId>GWTFZNYPVEQFW5XT</RequestId>
    <HostId>LlMv1YmDvqLUZxHP2Tj1CoQWxzhOuB/v/w5v8zzXgy8PkJFlZsJ5fQRKeLC1SlWiZZzlf9mcVWg=</HostId>
</Error>

代理服务打印的客户端请求信息:

/xxx/xxx/1266d18a32a32fcf9675705bfb3a05f2/5ac28032aec305dfe4006cebdc8ed6ab.jpeg 

authStr="AWS4-HMAC-SHA256 Credential=xxx/20230608/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=4f2639adf461283de1a1976d2af721df4b410f33969c98b6936f008895dedbbf" 

header={"content-length":"100792","content-type":"image/jpeg","host":"upload.xxx.com","x-amz-content-sha256":"UNSIGNED-PAYLOAD","x-amz-date":"20230608T122913 AMZ","x-amz-security-token":"FwoGZXIvYXdzEDIaDIMQ+d6Q5/8HZWA/4SLXAl2ndBDJPaHkleFSTMuCHMSlCmviOY4pKzor3GedYQ/5YZEp/omWvFIVjfVODqmLk9u+X47/yA+HCqraKk6Hg/1n3pS/j5OHgwhv+c5dRfKP4Rjs6Em0okPAAR/CdZg53K3TxSBWMqvi8c+wkPM6apSKNc8Pj2S9/uPXkJEu5OyeCPD6JomybI5TczCZaTt4YN2Z7h27ROy6ZtCj+N8KIqZoERQUGH9/IM33AVqeaDU8JIrU3+bHKYVIk5qpFzQQnuYiJleybmwMAyaHjzaJpm6dX+XWQ8BQLjaUkfn2tE45o2/xivtcRixW1BvU1fKJMeXqBkOd7dXBzOyILAM1cJRpU/YFslG71ghwWTe067rAQS+nQqfGCP7N2f3vG2vjfU4u0FujWug259jBf5urj+KLqznDB9W1a9UNy7xRMZnl4C7T5GRNCfqNAtFG1vfG+RGK42YCkF8o2cGEpAYyKebyLKPJqXT2nmauo4AfAm/joTnCgmGpu3RSE49Rt69KWrp4rf/qSMrG"} 

reqBody size is 100792

其中请求头x-amz-date的值‘20230608T122913 AMZ’格式有问题,正确应该是20230609T002913Z。

其实这个问题通过抓包就能找出问题,但由于设备是用户的,我们无法要求用户帮忙抓包。然后就是AWS的s3服务不打印请求的详细信息,所以无法通过查看s3的日记定位。

#中间件

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

cpu负载高故障排查实战-网关故障导致业务请求堆积

因为go标准库实现tls握手性能比较差,在一台8核的机器,只能到达2000这个量级,所以当到达某个临界点的时候,握手占用CPU过高,反过头来影响正常的业务请求,导致了业务请求处理变得十分慢。

Go写的文件上传中间件内存泄露问题排查

用go开发的一个文件上传中间件,由于依赖了ceph这个c库,早期通过pprof排查,怀疑内存泄露在c层,而项目依赖ceph,于是就怀疑是ceph的问题。但通过使用jemalloc排查后,并未发现ceph有什么异常。最后使用最笨的方法,定位到github.com/chai2010/webp库存在内存泄露bug。

组件和框架初始化顺序背后隐藏的线上故障

一个微服务可能引入非常多的SDK,例如消息中间件kafka的组件、RPC框架dubbo、定时任务调度平台xxl-job的组件,以及提供web服务的jetty/tomcat等。这些组件的初始化是不确定的,那么假如启动初始化过程中,其中某个组件初始化失败了,会发生什么?

Go调用Lua性能压测与调优

基于go提供的基准测试能力编写并发测试用例,为排除脚本本身的性能影响,脚本只实现简单的逻辑,并实现预编译。通过调整虚拟机池策略、cpu数、并行度等,输出调用lua脚本的平均耗时、占用的内存。

被开源组件坑惨了,文件上传到MFS后MD5不一致

moosefs没有关于底层自定义二进制通信协议的文档,且各大版本api上差异很大。我们在github上找到一个go语言实现api操作moosefs的开源库,但不幸的是,这个组件实现的api版本很低,在测试阶段,我们发现上传文件到moosefs后,moosefs上存储的文件的md5与本地原文件md5不一致,如果是图片,能很明显的看出少了一块像素。

基于dubbo-go二次开发荔枝RPC框架

本文介绍如何基于dubbo-go的扩展点,二次开发支持公司内部rpc协议,支持java项目和go项目的互相调用。