bug: SQS API is not respecting the region defined in request headers

[shadowhand]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Since version 0.14.3 localstack's SQS API no longer looks for the region defined in the Authorization header generated by the SDK, which means that any queues URLs created using the legacy strategy are only accessible in us-east-1.

Expected Behavior

When my SDK is configured with region, I expect that localstack services will respect that configuration. The SDKs, or at least the PHP SDK, send the region as part of the Authorization header:

  "Authorization" => "AWS4-HMAC-SHA256 Credential=test/20220520/us-west-2/sqs/aws4_request, /* snip */"

Note the region is contained in 3rd section of Credential. The problematic behavior appears to be written here in sqs/query_api.py, which makes no attempt to check for the region in the Authorization header, or in fact if the header even exists.

When I configure localstack with PROVIDER_OVERRIDE_SQS=legacy the problem immediately goes away and I can use the SDK without issue.

How are you starting LocalStack?

With a docker-compose file

Steps To Reproduce

How are you starting localstack (e.g., bin/localstack command, arguments, or docker-compose.yml)

docker compose up -d

Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands)

aws --endpoint-url="http://localhost:4566" \
  sqs get-queue-attributes \
  --queue-url "http://localhost:4566/000000000000/jobs-failed" \
  --attribute-names QueueArn

Environment

- OS: Mac OS 12.3
- LocalStack: 0.14.3

Anything else?

No response

[github-actions]

Welcome to LocalStack! Thanks for reporting your first issue and our team will be working towards fixing the issue for you or reach out for more background information. We recommend joining our Slack Community for real-time help and drop a message to LocalStack Pro Support if you are a Pro user! If you are willing to contribute towards fixing this issue, please have a look at our contributing guidelines and our developer guide.

[shadowhand]

The problem also goes away if I use SQS_ENDPOINT_STRATEGY=path and update my hard-coded development URLs to the expected format. It would still be preferable that the Localstack SQS API be consistent with the AWS API with regard to region configuration.

[shadowhand]

Refs #5928

[thrau]

hey @shadowhand, thanks for reporting.

It would still be preferable that the Localstack SQS API be consistent with the AWS API with regard to region configuration.

TL;DR: it is now, it wasn't previously.

in principle this is expected behavior, because (from my understanding) with AWS, the region is encoded either explicitly or implicitly in the queue. creating a jobs-failed queue in us-west-2 will give you a queue url that looks like https://us-west-2.queue.amazonaws.com/000000000000/jobs-failed or for us-east-1 https://queue.amazonaws.com/000000000000/jobs-failed (which is the default region so it's implicit) if you're trying to send a request to https://queue.amazonaws.com/000000000000/jobs-failed (which is a queue in us-east-1) that's signed for us-west-2 (which contains the auth header you described), then aws will complain.

we wanted to have that same behavior, and in http://localhost:4566/000000000000/jobs-failed the region of the queue is ambiguous. using the headers like we did previously to resolve the queue URL is simply not the way that AWS behaves.

i feel inclined to just say "sorry for breaking your code, but please use SQS_ENDPOINT_STRATEGY=domain or SQS_ENDPOINT_STRATEGY=path (if you cant resolve localstack domains)" which is IMO the cleaner solution.

but i think a case can be made for something like a fourth endpoint strategy which is =headers that will restore the old behavior and resolve the queue URL from the signing header (which again is from my understanding not how AWS works)

please share your thoughts :-)

[shadowhand]

All of that makes sense and we did switch to using the new provider with "path" strategy.

The problem is more that this was done in a minor release version with no warning or backwards compatibility in place, and it broke our entire development stack for the better part of day.

Once I realized that localstack had updated I was able to read the change log and figure out how to upgrade.

[thrau]

point taken, and apologies for that! we are working on updating the release strategy soon and making breaking changes more visible!

closing for now, glad the path strategy is working for you!