[pull] series/0.19 from disneystreaming:series/0.19 - #113
Merged
Merged
Conversation
The SigV4 signing name and the endpoint host were both derived from `endpointPrefix`, which is only correct for services where the two happen to coincide. They are separate things. `aws.auth#sigv4`'s `name` is defined as "the signature version 4 service signing name to use in the credential scope when signing requests", so the signing name now comes from there, falling back to `arnNamespace` and then `endpointPrefix`. The host keeps using `endpointPrefix` -- the field documented for endpoint resolution -- and falls back to `arnNamespace`, which is DNS-safe by construction, for the services that omit it. This fixes two failure modes: - Services whose prefix and signing name differ were signed with the wrong credential scope and rejected by AWS with "Credential should be scoped to correct service". SES v2 is hosted at `email.<region>.amazonaws.com` but must be signed as `ses`; SageMaker is hosted at `api.sagemaker.<region>.amazonaws.com` but signs as `sagemaker` (#1568). - Services with no `endpointPrefix` fell back to the *operation* name for the host, producing nonsense like `ListRegions.us-east-1.amazonaws.com` (#1532). The Account API's own endpoint tests confirm the expected host is `account.us-east-1.amazonaws.com`, so this needs no rule-set evaluation. Adds fixture services to `sampleSpecs/aws_example.smithy` covering each combination of `endpointPrefix`, `arnNamespace` and sigv4 name seen in the wild, plus DynamoDB (where all three agree) as a no-regression case. Four of the five new assertions fail without this change. Verified against real AWS with read-only calls: Account.ListRegions and Account.GetAccountInformation reach `account.us-east-1.amazonaws.com` signed as `account`, and SageMaker.ListEndpoints reaches `api.sagemaker.us-east-1.amazonaws.com` signed as `sagemaker`. Also skips traits from the `aws.endpoints` namespace when generating hints, mirroring the existing treatment of `smithy.rules`. Those traits have no published Scala bindings, so any service carrying them -- the Account API among them, via `aws.endpoints#standardPartitionalEndpoints` -- generated a reference to `aws.endpoints.StandardPartitionalEndpoints` that did not compile. That made the #1532 service unusable even with the host fix in place. Note: `X-Amz-Target` is still set for every protocol though it belongs to awsJson1_0/1_1 only. Left alone deliberately -- the header is part of the canonical request, so changing it alters every signature, which does not belong in a correctness fix. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )