S3 Signing Errors
• Mark Eschbach
Sometimes my hair is on fire. And sometimes, just sometimes, I’m on fire.
As a result of introducing dots into the bucket names we’re seeing an interesting class of errors from tools utilizing S3. It’s really interesting actually. I’ve already resolved the storage issue by migrating to Boto3. Unforunately creating authorized URLs for the clients is having a bit of an issue.
The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint. It appears as though
django-storages is still trying to use the CDN target.
RTFMing didn’t resolve the issue. No real mention of target endpoints. I’m wondering if I can override the
endpoint_url to follow a similar tact as it already is:
https://s3.amazonaws.com/<bucket.name> instead of
<bucket.name>.s3.amazonaws.com. With the power of
endpoint_url = "https://s3.amazonaws.com/" + self.bucket_name. Hmm, I had to put in the constructor.
By appending the bucket name I found it duplicated in the output. Trying
"https://s3.amazonaws.com/". While waiting for that to ship to the testing environment I found
AWS_S3_CALLING_FORMAT which defaults to using subdomains. I wonder if there is an easy way to override that value. As it turns out there isn’t an analog on the
S3Boto3Storage object. Instead there is a configuration element named
addressing_style which looks like it will resolve the issue. According to the boto3 documentation this should be easy enough to resolve. Let’s see how it works.
That didn’t work. At this poiint I’m going to add bucket’s not having periods in their names as a best practice.