nhost / hasura-storage

Storage for Hasura built on top of S3

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error using a subdomain style s3 repo

bestmazzo opened this issue · comments

Hello,
I've been successfully using hasura-storage 0.6.0 in a staging environment, leveraging a minio service, in a k8s architecture.

Now I'm planning to move to a production env, and there I'll be using s3 in a subdomain hosted by a third party provider.
The endpoint will be in the form https://{BUCKET_NAME}.{REGION}.myprovider.com

So I set the hasura-storage image ENV VARIABLES:
S3_ENDPOINT: https://{BUCKET_NAME}.{REGION}.myprovider.com
S3_BUCKET: {BUCKET_NAME}
S3_REGION: {REGION}

I'm currently having issues with such configuration, as I keep getting a 403 error when trying to upload a file.

 errors="[problem processing request: problem uploading file to storage: problem putting object: operation error S3: PutObject, https response error StatusCode: 403, RequestID: a197b1b2-0f2a-567107630, HostID: , api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.]"

Digging into the code, I noticed this line:

o.UsePathStyle = true

So I presume, hasura-storage assumes we're always using a path-style repo, so signature calculation may never be correct in a subdomain scenario

Am I doing something wrong?
Should I just provide ENV VARs in a different form?
Or do we need to make UsePathStyle option available from ENV VARs in order to cover such deployment scenarios?

Thank you for your help

Or do we need to make UsePathStyle option available from ENV VARs in order to cover such deployment scenarios?

I guess so, I am not familiar with that type of configuration so I can't say for sure.

Looking at AWS SDK, seems this could be the right param to change in such scenarios.
I can try and make a PR, but I'm not used to GO programming, so just tell me what you prefer..