我在DRF和某个API调用中使用令牌身份验证,想要重定向到S3(使用像https://my_bucket.s3.amazonaws.com/my/file/path/my_file.jpg?Signature=MY_AWS_SIGNATURE\u0026amp这样的URL ; AWSAccessKeyId = MY_AWS_ACCESS_KEY_ID).但是,我从AWS收到以下错误：
很清楚为什么会发生这种情况 – 带有DRF令牌的Authorization标头会随着重定向传播而S3不喜欢它.
在研究并尝试了一百万种方法来摆脱那个标题后,我放弃并决定尝试用S3值覆盖标题：AWS MY_AWS_SIGNATURE：MY_AWS_ACCESS_KEY_ID,之后我得到一个不同的错误：
如您所见,最终结果是相同的 – 即使我在响应中覆盖Authorization标头,它仍保留原始DRF令牌身份验证值.
# relevant portion of my response construction
headers = {'Location': 'https://my_bucket.s3.amazonaws.com/my/file/path/my_file.jpg','Authorization': 'AWS %s:%s' % (params['AWSAccessKeyId'],params['Signature'])}
return Response(status=status.HTTP_302_FOUND,headers=headers)
所以,我的问题是,如何删除或覆盖DRF响应中的Authorization标头？
例如,Paw,我查询我的API的工具包提供了这样的配置：
所以基本上,主流浏览器倾向于重定向授权标头,这导致S3上的冲突.
另外我怀疑你误解了重定向的执行方式：
>当DRF发出重定向时,它会向客户端返回HTTP 301或302响应,其中包含新的Location头(请求不是直接通过DRF“转发”)
>然后,客户端请求此新URI
最后,当你发出302时,你没有覆盖任何授权标题,因为这是对客户端的响应……(它可以携带授权标题但是没用).
现在,你有一堆解决方案(因此没有开箱即用……)：
>将令牌传递到不同的标头以避免冲突(例如X-Token)
>通过HTTP GET参数传递令牌(？token = blah)
>使用DRF视图代理S3对象(不重定向)
前两个解决方案可能会以某种方式破坏API的一致性,但在某种程度上是公平的.他们需要自定义TokenAuthentication或get_authorization_header(来自rest_framework.authorization).
最后一个是透明的,但可能完全不适合,具体取决于您在S3上获取的对象和/或您的托管约束…
这就是我现在可以告诉你的全部内容.如你所知,I’ve been stuck with the same situation too.如果有人能提出更好的解决方案,我会很高兴的.