I generate S3 credentials from the CLI. The access works fine, but for JS libraries minio S3, AWS-S3 v2 and AWS-S3 v3 the clients do validation for the v4 signature endpoints. I get the error below.
Based on various Githubs, it looks like this is a minio config setting on the gateway side.
The error spit out is the following:
SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
We are sorry you are having these issues with the minio endpoint. We have escalated the issue to our dev team who are currently in the process of trying to replicate it and will post a reply as soon as possible.
The primary reason I could think this might not work is invalid credentials. Hereās an example with AWS SDK v2 for JavaScript with test credentials set up: Edit fiddle - JSFiddle - Code Playground. One of the ways to troubleshoot this might be to double-check credentials passed to the constructor and/or try them with that example (you can create a test bucket and a test file or use existing ones).
This was the command I used to generate the creds uplink share --readonly=false --not-after +1h --register sj://${process.env.STORJ_BUCKET}/${prefix}/ --auth-service=https://auth.us1.storjshare.io
I also downgraded to AWS-sdk which is the v2 API and supports signatureVersion: v2. I added that field in and it still DID not work. This is super frustrating.
Perhaps you could try adding some logging to see if requests are being made, and it may shed some light on the problem. I used the example of adding a middleware from this post and was able to get a formatted request object logged to the console: AWS JavaScript SDK v3 - usage, problems, testing - Better Dev
Hereās an example of it running with NodeJS which uploads a test file to a bucket and logs the request: s3_put_object_storj.js Ā· GitHub. I installed the dependencies using npm install @aws-sdk/client-s3.
The request appears to look correct, glancing at the auth headers. I noted that the body in the request log shows as []. Perhaps thereās something with the body causing requests to have an invalid signature. Perhaps you could try setting the Body field in PutObjectCommand params to something like ātestā to see if that works?
I wonder if other requests like ListObjectsCommand works for you, or do you still get invalid signature errors for those too?
I took the keys generated here, passed it to my same S3 uploading code, and viola, all my uploads worked as expected. However, I need the time bound because I need keys to expire.
Could you try replicating my scenario with code to help me debug this please? The error is likely Storj related, or will be a very specific S3 config change that an average developer like myself probably wonāt find.
I tried to replicate your code as close as possible, although Iām not sure how to replicate the RNFS.readFile() part. Perhaps you could share some more code so that I could?
I tried a restricted credentials as well and it seemed to work. I had a random thought that perhaps the clock on your computer or server may have drifted which could cause these signature problems. Could you try generating restricted credentials with a longer time, such as +24h or +48h to see if we could rule that out as an issue?
After a lot of bug investigation, this was an issue with my own code. The expiration wasnāt related to this.
Long story short, the Storj NodeJS binding would have been my ideal way to issue credentials. However, there wasnāt support for S3 at the time, and installing through yarn/npm was flaky. I had to write my own wrapper around the CLI and there was a tiny bug there causing these issues.
Thank you to the Storj team for helping out. Their response times were pretty helpful.