Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signature mismatch issue with S3Client #6618

Open
3 of 4 tasks
GowthamShanmugam opened this issue Nov 3, 2024 · 5 comments
Open
3 of 4 tasks

Signature mismatch issue with S3Client #6618

GowthamShanmugam opened this issue Nov 3, 2024 · 5 comments
Assignees
Labels
bug This issue is a bug. p2 This is a standard priority issue

Comments

@GowthamShanmugam
Copy link

Checkboxes for prior research

Describe the bug

I am faceing a similar issue, In react I am using S3Client with endpoint: proxy_url.

const client = new S3Client {
      endpoint: 'http://localhost:9000/s3-path',
      forcePathStyle: true,
      credentials: {
        accessKeyId: accessKeyId,
        secretAccessKey: secretAccessKey,
     }
 } 
 
 client.send(new ListBucketsCommand());

The server will receive this request at localhost:9000/s3-path and redirect it to s3-test.devcluster.openshift.com.

The same signature mismatch error is appearing for me. X-Amz-SignedHeaders=host is the issue. To generate the signature, the first call used localhost:9000 as the host. However, the host header that the S3 server receives is s3-test.devcluster.openshift.com. It results in a mismatch in signatures.

How do i resolve this issue?

Regression Issue

  • Select this option if this issue appears to be a regression.

SDK version number

"@aws-sdk/client-s3": "3.667.0",

Which JavaScript Runtime is this issue in?

Browser

Details of the browser/Node.js/ReactNative version

md/browser#Chrome_129.0.0.0

Reproduction Steps

N/A

Observed Behavior

Error Loading : The request signature we calculated does not match the signature you provided. Check your AWS secret access key and signing method. For more information, see REST Authentication and SOAP Authentication for details.

Expected Behavior

It should return list of buckets

Possible Solution

No response

Additional Information/Context

No response

@GowthamShanmugam GowthamShanmugam added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Nov 3, 2024
@aBurmeseDev aBurmeseDev self-assigned this Nov 5, 2024
@zshzbh
Copy link
Contributor

zshzbh commented Nov 5, 2024

Hey @GowthamShanmugam,

I understand you're facing a signature mismatch error when using the S3Client in React with a proxy setup. Similar issue reported before - https://repost.aws/questions/QUHe03UXDtR-Ou5VS7exfK9w/making-s3-api-calls-through-and-nginx-reverse-proxy

To adress this problem, you can use a custom signer that overrides the host used in the signature calculation. Here's how you can modify your code to implement this solution:

  1. Import packages:
import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";
import { SignatureV4 } from "@aws-sdk/signature-v4";
import { Sha256 } from "@aws-crypto/sha256-browser";
  1. Create a signer function
const createCustomSigner = (region, credentials) => {
  const signer = new SignatureV4({
    credentials: credentials,
    region: region,
    service: 's3',
    sha256: Sha256
  });

  return async (request) => {
    request.headers.host = 's3-test.devcluster.openshift.com';
    return signer.sign(request);
  };
};
  1. Add the configs
const client = new S3Client({
  endpoint: 'http://localhost:9000/s3-path',
  forcePathStyle: true,
  region: 'your-region', // Replace with your S3 region
  credentials: {
    accessKeyId: accessKeyId,
    secretAccessKey: secretAccessKey,
  },
  signer: createCustomSigner('your-region', {
    accessKeyId: accessKeyId,
    secretAccessKey: secretAccessKey,
  })
});

Please try the steps posted above and let me know if that solves the issue

Thanks!
Maggie

@zshzbh zshzbh assigned zshzbh and unassigned aBurmeseDev Nov 5, 2024
@zshzbh zshzbh added p2 This is a standard priority issue response-requested Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days. and removed needs-triage This issue or PR still needs to be triaged. labels Nov 5, 2024
@GowthamShanmugam
Copy link
Author

GowthamShanmugam commented Nov 6, 2024

This solution is not working, requests do not have any field called header

request{
  disableDoubleEncoding: true 
  name: "sigv4"
  signingName: "s3"signing 
  Region: "none"
}

I tried adding a header and host in the request before assigning it to the signer.sig but still the same issue.

Also return signer.sign(request); type is not assignable to signer

@GowthamShanmugam
Copy link
Author

GowthamShanmugam commented Nov 6, 2024

I changed the code to

const createCustomSigner = (region, credentials): RequestSigner => {
  const signer = new SignatureV4({
    credentials: credentials,
    region: region,
    service: 's3',
    sha256: Sha256
  });

  return {
    sign:  (request: HttpRequest) => {
    request.headers.host = 's3-test.devcluster.openshift.com';
    return signer.sign(request);
  }};
};
signer: createCustomSigner('auto', {
        accessKeyId: accessKeyId,
        secretAccessKey: secretAccessKey,
 })

But it gives the same issue, the host value is changing in the header but I am not sure why signature creation still using the old host.

@zshzbh
Copy link
Contributor

zshzbh commented Nov 6, 2024

Hey @GowthamShanmugam ,

I found this thread would be helpful.

You can change the request to

 const request = new HttpRequest({
        headers: {
            "Content-Type": "application/json",
            host: host,
        },
        hostname: host,
        method: "POST",
        path: `${index}/_search`,
        body: JSON.stringify(query),
    });

And sign request like this :

const signer = new SignatureV4({
        credentials: creds,
        region: region,
        service: "es",
        sha256: Sha256,
    });
    const signedRequest = await signer.sign(request);

@GowthamShanmugam
Copy link
Author

Does that mean I can't use S3Client? May I know why Signature is still using the old header? from where it is getting the header?

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days. label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. p2 This is a standard priority issue
Projects
None yet
Development

No branches or pull requests

3 participants